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FOREWORD 


Computer-aided Acquisition and Logistic Support (CALS) is a DoD 
and Industry strategy to enable, and to accelerate, the 
integration of digital technical information for weapon system 
acquisition, design, manufacture, and support. CALS will provide 
for an effective transition from current paper-intensive v Weapon 
system life cycle processes to the efficient use of digital 
information technology. The purpose of CALS is to improve 
industry and DoD producti.-ity and quality, and thus improve 
supportability, military readiness, and combat effectiveness. 

The objectives of CALS are: 

a. To accelerate the integration of design tools such as 
those for reliability and maintainability into contrac¬ 
tor computer-aided design and engineering systems as 
part of a systematic approach that simultaneously 
addresses the product and its life cycle manufacturing 
and support requirements. 

b. To encourage and accelerate the automation and integra¬ 
tion of contractor processes for generating weapon 
system technical data in digital form. 

c. To rapidly increase DoD's capabilities to receive, 
store, distribute, and use weapon system cechnical data 
in digital form to improve life cycle maintenance, 
training, and spare parts reprocurement, and other 
support processes. 

Currently, a variety of automated systems are utilized by weapon 
system contractors working as a production team to enter, update, 
manage, and retrieve data from data bases associated with speci¬ 
fic acquisition programs. Many of these systems are incompatible 
with one another other as well as with similar systems employed 
by the government to receive, store, process, and use delivered 
technical data. The functional capabilities supported by these 
diverse systems vary greatly. Data created in one functional 
process is often manually re-entered or re-created in subsequent 
functional processes, thereby introducing errors and increasing 
costs. 

The near term goals for CALS implementation are attainment of 
increased Ic^^els of interfaced, or integrated, functional 
capabilities, and specification of requirements for limited 
government access to contractor technical data bases, or for 
delivery of technical data to the government in digital form. 
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These specifications are designed to comply with widely accepted 
commercial standards developed for these purposes. 

The longer term goal of CALS is integration of industry and DoD 
data bases to share common data in an Integrated Weapon System 
Data Base (IWSOB) structure that is implemented through 
Contractor Integrated Technical Information Systems (CITIS) and 
government technical information systems deliverables 

from, or government access to, specified segments of CITIS data 
will be explicitly required in future contracts, developed in 
accordance with CALS standards and procedures. The technology to 
accomplish this will be incrementally implemented as it is 
developed and proven. DoD and industry will be implementing a 
mixture of current and emerging technologies throughout the 
1990's. 

This handbook applies to programs for acquisition and support of 
weapon systems and related major equipment items (including 
support systems) to which DoDD 5000.1, DoDI 5000.2, or DoDD 
5000.39 apply. Policy guidance issued by the Deputy Secretary of 
Defense on August 5, 1988, (Appendix A, figure 3) requires 
acquisition managers to evaluate CALS capabilities in source 
selection decisions and to implement cost effective CALS 
requirements in contracts for weapon systems and related major 
equipment items. To aid acquisition managers in implementing 
this policy, this military handbook provides: 

o An overview of Computer-aided Acquisition and Logistic 
Support. 

o A summary of the various ways in which digital data can be 
used and the forms in which digital data can be procured or 
accessed. 

o A set of decision criteria to apply when evaluating 
alternative digital data delivery and access options. 

o Model contract language for contractor integration of 

specific functional capabilities, delivery of digital data, 
and government access to contractor-maintained data bases. 
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1. SCOPE 

1.1. Purpose. The purpose of this military handbook is to 
provide general information and detailed application guidance for 
contractually implementing Computer-aided Acquisition and 
Logistic Support (CALS) requirements in weapon system and related 
major equipment procurements. 

1.2. Scope. This handbook describes functional requirements and 
technical standards applicable to all programs for acquisition 
and support of weapon systems and related major equipment items 
(including support systems) to which DoDD 5000.1, DoDI 5000.2, or 
DoDD 5000.39 apply, and for which the acquisition of technical 
data in digital form is required in accordance with MIL-STD-184C, 
MIL-STD-1388-2, and supporting military specifications. This 
handbook also addresses those specific functional capabilities 
requiring integration by the contractor to support weapon system 
acquisition. 


2. REFERENCED DOCUMENTS 

See list of references appearing in Appendix A. 


3. DEFINITIONS 

See list of terms and acronyms appearing in Appendix A. 
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4. GENERAL GUIDANCE 

4.1. Purpose. Computer-aided Acquisition and Logistic Support 
(CALS) is a Department of Defense (DoD) and industry strategy to 
enable, and to accelerate, the integration of digital technical 
data in standard form for weapon system acquisition, design, 
manufacture, and support. The intent of CALS is to improve 
industry and DoD productivity and quality. This leads to 
improved supportability, and to increased readiness and opera¬ 
tional effectiveness. 

4.2. Digital technical data. A primary CALS thrust is 
automation and integration of the generation, delivery, and use 
of weapon system technical data over the weapon system's life 
cycle. This technical data includes the part descriptions, 
product specifications, and standards that the initial designer 
draws upon; the engineering drawings and product data used in 
design and manufacturing; the information needed to guide the 
people who operate the system in the field, or who support and 
maintain it at all echelons of the logistic support structure; 
the materials needed to train new operators, maintainers and 
other technicians; and the information needed for reprocurement, 
remanufacturing, modification, and feedback to industry for 
future design. CALS has published technical standards which 
enable either delivery of this information in digital form or 
government access to contractor-maintained technical data bases. 
A more complete discussion of CALS is found in Appendix A. 

4.3. CALS requirements in weapon system accjuisition. Policy 
guidance issued by the Deputy Secretary of Defense (see Appendix 
A, figure 3) requires that plans for new weapon systems and 
related major equipment items include use of the CALS standards. 
Specifically: 

a. For systems entering full scale development or 
production prior to September 1988, acquisition 
managers are required to review specific opportu¬ 
nities for cost savings or quality improvements 
that could result from changing paper deliverables 
to digital delivery or access using the CALS 
standards. 

b. For systems entering development after September 
1988, specific cost and schedule proposals should 
be obtained for: (1) integration of contractor 
technical informfition systems and processes, (2) 
authorized government access to contractor data 
bases, and (3) delivery of technical information 
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in digital form. These proposals shall be given 
significant weight for their cost and quality 
implications in source selection decisions. The 
CALS standards are to be applied for digital data 
deliverables. 

4.4. CALS requirements in automated data processing system 
acquisition. CALS implementation involves the participation of 
both weapon system acquisition managers, and government and 
industry automated data processing system managers. Acquisitions 
of future computer hardware, software, and telecommunications 
must address CALS data interchange and access requirements. The 
key to supporting these requirements is an open architecture that 
can cost effectively support future as well as current data 
interchange and access needs. Although the audience for this 
handbook is the acquisition manager for weapon systems and 
related major equipment, automated data processing system 
managers should also be familiar with its contents. The Deputy 
Secretary of Defense policy guidance provided as Appendix A, 
figure 3, requires DoD components to program for automated 
systems to receive, store, distribute, and use weapon system 
technical data in digital form in accordance with the CALS 
standards. 

4.5. Application guidance. A general framework for implementing 
CALS requirements is provided in Section 5.1, followed by 
detailed guidance on choices among digital data delivery and 
access alternatives. Information on digital data requirements 
for specific functional areas, functional integration 
requirements, and delivery modes is provided in Appendices B, C, 
and D, respectively. Other acquisition issues, including data 
protection and integrity, are addressed in Appendix E. 

4.5.1. Contract data requirements. Contract Data Requirements 
Lists (CDRL's) and Data Item Descriptions (DID's) from previous 
contracts may not take advantage of automated capabilities 
available in current acquisition programs. Acquisition managers 
should identify new requirements in invitations for bid. In 
Requests for Proposal (RFP's), the acquisition manager should 
task contractors to conduct tradeoff studies to identify improved 
methods for data delivery or on-line access. Contractors should 
work with acquisition managers and contract administration 
activities to implement on-line access to data files, and to 
establish guidelines defining the actions on the part of the 
contractor and government that constitute delivery and acceptance 
of data which may remain resident at the contractor's facility. 
Contractors should also identify redundant data deliverables or 
multiple reports which can be produced from a single data file. 
Contractors should propose implementation of alternate delivery 
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methods; for example, by proposing delivery of LSAR Master Files 
to fulfill multiple CDRL items for hard copy reports. In some 
cases, technical data in digital form can be acquired with 
existing DID's, while in other cases new DID's must be developed. 
Appendix B provides additional guidance. 

4.5.2. Government furnished information. An important subset of 
data required to support the acquisition of weapon systems is 
generated by the government and provided to the contractor as 
government furnished information. The acquisition manager should 
provide this information in digital form whenever possible. 

RFP's should specify contractor responsibilities for the integra¬ 
tion of government furnished information with contractor¬ 
generated data in preparation of documents, processable files, or 
data bases for interactive access. 

4.5.3. Guidance for subcontracting. The acquisition manager and 
potential prime contractors should jointly pay particular 
attention to data requirements that will flow down to subcontrac¬ 
tors and suppliers. Requirements for delivery of digital data by 
prime contractors should reflect cost-effective delivery of 
sub-tier data where needed. Hard copy, microfilm, or non¬ 
standard digital data should be evaluated when life cycle costs 
may not support delivery of digital data in standard form by all 
subcontractors and suppliers, but delivery in standard digi^ al 
form is the preferred mode. The mix of format requirements 
should be formalized and documented in block 16 (Remarks) of the 
CDRL (DD Form 1423) before contract award. When the mix of 
format requirements cannot be determined until after contract 
award, those requirements must be formalized as a contract 
modification. 

4.5.4. CALS application to small business. Small business makes 
up a substantial portion of DoD contractors and subcontractors. 
The policy guidance by the Deputy Secretary of Defense (Appendix 
A, figure 3) directs special attention to opportunities and 
safeguards for small businesses operating in a CALS environment. 
Small business should not be put at a disadvantage because of 
limited resources for the investments needed to comply with CALS 
data delivery, data access, and functional integration 
requirements. 

4.6. Government receiving systems. Contractor-generated digital 
data must be supported by government receiving systems that can 
access, receive, process, and distribute digital technical data 
using CALS specifications and standards. Government receiving 
systems are being established in the military departments and 
agencies during 1989-1995 for digital engineering drawings, 
technical manuals, and other technical data. Acquisition and 
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delivery of, or access to, this digital data must be phased to 
coincide with incremental upgrades to the government hardware, 
software, and procedures which constitute the receiving 
infrastructure. Where appropriate, the acquisition manager must 
consider the status of the receiving infrastructure within the 
acquiring Service, other Services, and the Defense Logistics 
Agency. Service and Defense Logistics Agency CALS offices listed 
in Appendix A can provide status information and additional 
guidance on time phasing. 

4.7. Functional capabilities. The functional capabilities 
described in Appendix C constitute an evolutionary program to 
achieve functional integration within contractor processes and 
the supporting CITIS. The acquisition manager should apply the 
general guidance of Appendix C in the preparation of solicitation 
documents and resulting contracts. The acquisition manager may 
tailor the detailed requirements as necessary to support the 
acquisition strategy selected for the weapon system. 

4.8. Data protection and Integrity. DoD policies and 
acquisition regulations regarding data protection and integrity 
in the paper-based environment also apply to the CALS digital 
environment. Control of the system, data base, and associated 
data maintenance and configuration control responsibilities are 
important issues. These issues require consideration in the 
design of both Contractor Integrated Technical Information 
Systems (CITIS) and government technical information systems. 

This includes restricted access/change procedures, audit trails, 
and electronic marking of digital deliverables where appropriate. 
Aa an early contractual task, acquisition managers should require 
the contractor to provide a detailed plan that describes the 
procedures and specifications to be used in the integration, 
digital exchange, and sharing of data with the government and 
other contractors, including satisfactory security requirements. 
Government technical information system managers must share with 
CITIS managers responsibility for protection of classified, 
proprietary, or otherwise sensitive information (see Appendix E). 
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5. DETAILED GUIDANCE 

5.1. Acquisition requirements. The integrated set of automated 
data processing systems and applications that vill be used by the 
weapon system contractor team to enter, update, manage, and 
retrieve data from specific weapon system technical data base(s) 
is called the Contractor Integrated Technical Information System 
(CITIS). The CITIS provides the automated data processing 
capability used by the contractor(s) to accomplish weapon system 
design, manufacture, and support processes. To take advantage of 
current contractor CITIS capabilities, the government acquisition 
manager should request contractor proposals such as those 
described in the following paragraphs. These contractor propo¬ 
sals will be evaluated for their cost and quality implications as 
part of the source selection process, and required under the 
subsequently awarded contract. This section describes contract 
requirements that could reasonably be expected to result from 
this process. 

5.1.1. General contract requirements. The solicitation or 
contract should state that an objective of the acquisition is to 
require the contractor to generate information products from all 
development and production functions in an integrated information 
system and a shared data environment. Ideally, this integration 
should be achieved as part of a comprehensive concurrent 
engineering strategy. The integrated environment will provide 
for generation, storage, indexing, distribution, and delivery of 
technical data products, and support weapon system development 
and production functions and processes. The objective is to 
create each data element once and use it repeatedly in subsequent 
processes without manual re-entry. The contractor should be 
required to provide and adhere to a comprehensive plan for 
meeting this objective. 

5.1.2. Contract implementation of digital data sharing and 
exchange. The contractor's CITIS should provide for the integra¬ 
tion, digital exchange, and sharing of data with the government 
and associated contractor(s). CITIS data base(s) should have the 
capability of distinguishing among, and providing visibility and 
accessibility of, the following data iterations: 

o Working Data - Government may be provided a read only 
capability for in-process review of selected initial or 
change data/information (using partitioned data bases 
or other appropriate techniques), as negotiated. 

o Submitted Data - The CITIS storing data released for 
review and approval must provide a method for incorpor- 
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ation of government-proposed changes and feedback to 
working data files, while maintaining version control 
and protection against unauthorized changes. 

o Approved Data - Data that have been reviewed and 

approved by the government or appropriate designee and 
requires additional controls against unauthorized 
changes. 

The contractor plan should provide a cost effective method of 
managing the CITIS such that appropriate configuration and 
version control of technical information is maintained, while 
providing current data for design, engineering analysis, 
manufacturing, and product support planning. The plan should 
address capabilities for digital demand reproduction of 
CAE/CAD/CIM/logistic technical data, and provide for digital 
exchange and integration among the logistics and other functional 
areas. 


5.1.3. CALS integration of Computer Aided Engineering (CAE), 
Computer Aided Design (CAO ), and Computer Integrated Manufac¬ 
turing (CZM) . The contractor should be required to provide for 
integration of logistics processes with CAE, CAD, and CIM 
processes. This includes other computer aided technologies, such 
as computer aided testing (CAT) and computer aided process 
planning (CAPP). This will assure that logistic resources are 
developed consistent with the configuration of the weapon system 
and changes thereto. Process integration should be accompanied 
by integration of the CITIS data elements supporting those 
processes. This will facilitate both integration of these 
processes, and configuration control of the data that supports 
the processes. Changes in the as-designed, as-manufactured, as- 
delivered, and as-supported configurations of the product can be 
reduced, associated technical data changes can be better 
controlled, and the quality of both the product and data about 
the product will be improved. 

5.1.4. Reliability, maintainability, and supportability. The 

inclusion of CAE capability in support of reliability and 
maintainability (R&M) development is best accomplished by making 
CAE support of R&M a source selection factor. The contractor 
should be required to describe the intended use of computer 
systems to provide: 

a. Automated R&M analysis procedures tightly coupled to 
parts libraries and to material characteristics data 
bases. 
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b. Automated R&M synthesis based on design rules incorpor¬ 
ating lessons learned from prior design experience and 
field use. 

c. Fully characterized (tested and validated) component 
performance and R&M characteristics data bases. 

d. Consistent data management procedures that link major 
design decisions affecting the R&M characteristics of 
the end item to the CAE software and data bases used to 
develop decision criteria and otherwise support the 
evolving configuration of the product. 

e. A structure of hardware, software, and computer net¬ 
works adequate to support the procedures and processes 
of "a” through "d” above, and to closely couple R&M 
specific resources (including personnel) with the rest 
of the design team. 

5.1.5. Integrated Logistic Support (ILS) management information. 
The contractor should be required to establish an on-line direct 
access system capable of recording, planning, scheduling, and 
reporting status of ILS program requirements. This system should 
provide visibility of the contractor's logistic support develop¬ 
ment performance, highlighting potential problems, and should 
provide schedule compatibility to assure logistic support 
integration. The on-line system should identify change impacts 
on related areas of logistic support and status of retrofit 
program deliverables. 

5.1.5.1. Interim/phased contractor support. The contractor 
should be responsible for providing on-line detailed status and 
accounting for interim/phased support programs as contracted. 

This will include status of all items inducted into a repair or 
maintenance program. Program status and accounting should be 
provided by digital means for accountability, and allow for 
transitioning interim support to the customer. The contractor 
should be required to conform with exchange standards for digital 
data transmissions between government and contractor activities. 

5.1.5.2. Government furnished equipment and information. The 
contractor should provide for update and maintenance of the 
government furnished equipment portions of the weapon system 
based on government review, and for input of other government 
furnished information such as usage data and reports of installed 
population by operating site. Wherever possible, government 
furnished information should be provided in digital form for 
direct input into the CITIS. 
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5.1.6. Supplier/vendor/subcontractor data requirements. The 
contractor should provide for capture and incorporation of 
required supplier/vendor/subcontractor data. This should include 
consideration of the capability of the supplier to use neutral 
interchange standards to deliver digital data that is compatible 
with the structure of prime contractor's CITIS where appropriate. 
It should also include alternatives such as providing terminals 
and/or access to lower tier subcontractors. 

5.1.7. Logistic support Analysis (LSA) and Logistic Support 
Analysis Record (LSAR) . The contract should require that data 
generated from the LSA program in accordance with MIL-STD-1388-1 
and maintained in the LSAR in accordance with MIL-STD-~1388-2 be 
the basis for logistics resource determinations. 

a. Support equipment - The contractor should be able to 
respond to government agency requirements for 
submission in digital form of support equipment 
recommendation data, with provision for visibility of 
government changes/approvals without loss of original 
documentation. 

b. Technical manuals/data - The contractor should provide 
for computer assisted generation of technical data. 
These data are to be derived, to the maximum extent 
possible, from integrated digital data files, e.g., 
CAO/CAE/CIM/LSAR. These data should be provided in 
accordance with contractually imposed functional 
specifications for technical manuals and other data 
(e.g., MIL-M-38784), the appropriate technical 
specifications (e.g., MIL-M-28001), in confonnance with 
MIL-STD-1840. 

c. Training and training equipment - The contractor should 
provide training system development with data generated 
and derived, to the maximum extent possible, from LSAR 
in accordance with MIL-STD-1388-1/-2 and from technical 
data in 5.1.7.b. 

d. Supply support - The contractor should provide 
provisioning technical documentation in accordance with 
MIL-STD-1388-2 to facilitate automated ordering, supply 
management, and distribution, and should provide on¬ 
line identification of spares, repair parts, and 
source/maintenance/recoverability coding linked to 
provisioning technical documentation. 

e. Facilities - The contractor should provide facilities 
requirements data in digital form. 











MIL-HDBK-59 


5.2. Acquisition of digital data products. This section 
provides guidelines for acquisition (including both delivery and 
access) of weapon system engineering and integrated logistic 
support data in digital form. Appendix B applies this decision 
process to specific logistic functional areas and data products, 
such as technical manuals and engineering drawings. Appendix D 
provides additional guidance on delivery and access mode options. 

5.2.1. Acquisition considerations. CALS is a strategy for 
accomplishing the transition from paper-intensive weapon system 
support processes to an automated and integrated form. It is not 
a mandate to accomplish all data acquisition digita''ly, regard¬ 
less of other considerations. The acquisition manager must base 
decisions concerning acquisitions of data in digital form in any 
life cycle phase on acquisition policy, on technology 
availability, and on analysis of costs and benefits. 

5.2.1.1. Data acquisition policy. DoD component policies and 
directives regarding the acquisition of digital data deliverables 
may govern preferred choices for specific applications and weapon 
system programs. These policies may address specific acquisition 
strategies, prime contractor/sub-tier contractor/vendor relation¬ 
ships and capabilities, existing Department/Agency automated data 
processing systems and other technical investments, future plans 
for automated CITIS and government systems, or other management 
considerations. Acquisition managers should contact the 
appropriate Military Department or Agency CALS Office listed in 
Appendix A for the most current policy directives to determine 
whether certain categories of data are already mandated for 
procurement as digital document images, processable files, or on¬ 
line access. 

5.2.1.2. Available technology. The availability of digital data 
processing and telecommunications technology, and approved 
standards for creation, storage, transmission, data protection 
and integrity, etc., of data at the time of delivery or access 
are important criteria for acquisition decisions. The current 
and projected capabilities of both the contractor and DoD 
agencies (Service and Defense Logistics Agency) must be assessed 
with respect to program needs and schedules. Acquisition 
managers should plan to acquire digital data products rather than 
hard copy unless a clear case can be made that the costs will 
outweigh the life cycle benefits. 

5.2.1.3. Heterogeneous environment. The rapid introduction of 
new technology will cause DoD and industry to operate in a mixed¬ 
mode, heterogeneous environment for many years. Some contractors 
with advanced capabilities will be on the leading edge of CALS 
IWSDB technology well before DoD is ready to put IWSDB specifi- 
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cations and standards in place. Many contractors are ready to 
implement current technology now, but will lag in the implemen¬ 
tation of future capabilities. DoD has some near term CALS 
capabilities in place, but generally is not yet ready to take 
advantage of all of the technology that is routinely used by 
defense contractors. And there is still a legacy of hard copy 
technical data: data produced for older weapon systems and still 
being maintained in hard copy form, hard copy data being 
generated now in response to contract requirements established 
several years ago, and hard copy data that will be generated in 
parallel with the introduction of digital data technology. 
Government must be prepared to support all of these technology 
levels, and contractor teams must expect to deal with several 
different levels of capability among team members. 

5.2.1.4. Cost/benefit analysis. Large productivity and quality 
gains are typically realized when technical data are created, 
stored, distributed, and used in digital form. However, initial 
investment expenses in automation and integration may not be 
offset by accrued benefits until later in the weapon system life 
cycle. It is important that the acquisition manager request 
bidders to provide comparisons of costs, cost avoidances, and 
benefits for alternative approaches for deliverables in their 
proposal. These comparisons should identify significant costs 
and benefits that are expected to accmie or be avoided throughout 
the weapon system life from both a contractor and government 
perspective, and the associated risks and tradeoffs. The 
analyses should be based upon program-specific guidance and 
factors provided by the government, and consider government 
planned capabilities to receive, distribute and use digital 
technical information. Results of the analyses should enable the 
acquisition management to assess relative risk as well as com¬ 
parative costs, anticipated benefits, and return of investments 
associated with implementing each alternative. 

Estimated costs should reflect all significant investments, 
transition, and operating expenses associated with the various 
CALS alternative approaches. Time-phased estimates of cost may 
consider, where applicable, categories such as: 

a. Capital costs associated with new equipment required 
for implementation and use. 

b. One-time and recurring costs for equipment operation, 
maintenance, and user training. 

c. Contractor data creation costs. 

d. Delivery and access expenses. 
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e. Government distribution and use costs. 

f. Ongoing data update, storage and maintenance costs. 

Benefits should be identified in terms of anticipated improve¬ 
ments in productivity and military operations. 

a. In terms of productivity, identify cost savings or 
avoidances associated with labor, materials and equipment, 
as well as time reduction for the actual data creation, 
delivery, distribution, update, maintenance, and use of 
technical information. In addition, program schedule 
impacts should be evaluated. For example, the ability to 
expedite engineering change proposals within full scale 
development may help to reduce the overall development time, 
or at least reduce the risk of costly program slippages. 
Other benefits associated with improved functional processes 
and technical information should be identified (and 
quantified if at all possible). 

b. Improvements to military operations may result due to 
increases in weapon system quality and performance, data 
accuracy, industrial and military responsiveness, readiness 
and sustainability. For example, fewer design problems 
should lead to more producible, reliable, maintainable 
weapon systems which ultimately effects readiness and 
sustainability. Improved data accuracy in technical manuals 
should improve the responsiveness and effectiveness of the 
maintenance process. Estimates of benefits should be 
quantified where possible. 

To the extent practical, the acquisition manager should include 
provisions for tracking costs and benefits as they accrue during 
the period of contract performance. Similar systems should be 
established within the government in order to gain a better 
understanding of the actual costs and benefits associated with 
CALS implementations. 

5.2.2. Life cycle phases. The weapon system's life cycle and 
acquisition phase are major factors in most digital data acquisi¬ 
tion decisions. All of the potential applications for the data 
throughout the life cycle must be considered early in the 
acquisition process. The contractor must have time to put in 
place the automated tools to create information in the 
appropriate digital form for future government delivery or 
access. The uses of the data change as the program progresses 
through its acquisition phases. In the early phases (e.g., 
Concept Exploration and Demonstration/Validation) of a program, 
data volatility is a key issue, and design changes are a frequent 
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occurrence. Interactive access may be preferable to static 
reports that are quickly outdated. 

5.2.2.1. Full scale development phase. As the program moves 
into full scale development, the volume of changes that require 
acquisition office approval rapidly increases. Interactive 
access could be justified to permit faster turnaround of change 
approvals and to help the program maintain schedule. 

5.2.2.2. Production phase. The majority of data is delivered 
during the production phase. The major data acquisition issues 
become the volume and types of technical data being procured, and 
appropriate configuration management requirements. Major consi¬ 
derations for the acquisition manager are: how will the data be 
used during the operational and support phase, and how will the 
data be delivered and distributed throughout the logistics 
organizations? 

5.2.2.3. Operation and support phase. The operation and support 
phase, which encompasses the longest period of time of any of the 
life cycle phases, sees the greatest use of old data and a 
continuing need for additional new data as product improvements 
and other changes evolve. Acquisition managers must plan 
carefully for the government organizations' ability to receive 
data in a form appropriate for its revision and use for many 
years downstream. Even if data was acquired through on-line 
access to a contractor CITIS, physical delivery of the data must 
be planned for at some point, such as when the weapon system 
finally goes out of production. 

5.2.3. Data processing categories. The acquisition manager must 
consider how data will be processed in order to make good deci¬ 
sions on digital data requirements and format. The five defined 
categories of data processing typical of most weapon system 
programs are archive, view, annotate/excerpt, update/maintain, 
and process/transform. In the following discussion, the five 
categories have been sequenced by level of sophistication, from 
simple archiving to very complex information processing and 
transformation. 

5.2.3.1. Archive. Archiving is the placing of data in a reposi¬ 
tory to preserve it for future use. Data may be archived in hard 
copy; however, future use of the data is enhanced when the data 
are prepared in digital form on media that allows automated 
retrieval. Digital data storage is also much more space 
efficient than any hard copy storage media. Legal questions 
remain on the certification of electronic records (digital data) 
as originals in lieu of hard copy. Use of digital deliverables 
may be limited for certain contract administration and accounting 
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functions. Data quality is usually more important than when 
immediate use of the data is planned, because the data may not be 
retrieved until after the experts who created it are no longer 
available to correct shortcomings. Early identification of the 
data repository for each life cycle phase is necessary to lay the 
foundation for required government and industry access for weapon 
system support. 

5.2.3.2. View. View is the ability to examine a data file 
without the ability to change it. It is the traditional service 
offered by early automated systems. It normally offers the 
options of screen display or hard copy output from a printer. 
Modern workstations and terminals, however, often include a local 
storage device, i.e., either a hard or floppy disk drive, so that 
anything displayed on the screen or output to a printer or 
plotter can be stored locally for later retrieval at the 
workstation without reestablishing a connection with the host 
computer. 


5.2.3.3. Annotate/excerpt . Annotate/excerpt is the ability to 
evaluate and highlight for future reference or to make annota¬ 
tions, approvals, and comments without the ability to change the 
original file. The extraction of relevant data for use in other 
documents, or for summarization purposes, is also provided at 
this level. The essential difference between annotate/excerpt 
and view is that annotations can be returned either as an overlay 
file or as a revised original file for processing by the host 
computer. This effectively allows changes to be made to the data 
while maintaining configuration control, although it is often 
cumbersome. For audit trails and version control, the 
acquisition manager should consider archiving these overlay and 
backup files, or requiring the contractor to do so through 
appropriate contractual tasking. 

5.2.3.4. Update/maintain. Update/maintain is the ability to 
change data, either directly or through controlling software, in 
the active files on the host computer. An example of this data 
processing type would be updating the government furnished 
equipment portion of an assembly drawing and associated parts 
lists. The service life of weapon systems may extend for thirty 
years or more; this longevity means that the supporting data has 
a similarly long life during which it must be updated, 
maintained, and controlled. 

5.2.3.5. Process/transform. Process/transform is the ability to 
extract and modify the format, composition, and structure of the 
data into another useable form. Process/transform entails the 
most complex processing of technical data. For example, computer 
aided design (CAD) data may be transformed into computer 
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integrated manufacturing (CIM) data for making spare parts on 
numerical control machines, or technical manual text and graphics 
data may be transformed into very specific troubleshooting 
maintenance aids for weapon system repair. 

5.2.4. Data acquisition decision process. Figure 1 is the 
master template that should be used by the acquisition manager to 
systematically determine how data should be delivered, or made 
accessible, to the government by the contractor. Application 
guidance for use of the master template for specific functional 
areas is provided in Appendix B. The decision points on the 
template aro not always exclusive and indicate a range of alter¬ 
natives open to the acquisition manager. That is, selecting one 
option at a decision point for a particular data product within 
one life cycle phase does not necessarily preclude the selection 
of other options for that same or other data products in other 
life cycle phases. On each weapon system program, the delivery 
media and technical use for each data product, contract line 
item, and CDRL item must be carefully evaluated. The evaluation 
process involves making four sets of decisions, as shown in 
figure 1, and explained in the following text. 
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5.2.4.1. Decision 1 - data deliverable type. The first decision 
point involves evaluation of three data deliverable types; docu¬ 
ments, processable data files, and interactive access. Then a 
three types differ in their flexibility and in the variety of 
data applications they can effectively accommodate. The first 
option is a document (such as a drawing, manual, or report) in 
either hard copy or digital form. Utility of documents is much 
more limited than the other deliverable forms because the data 
has already been processed into a finished technical data 
product. The second option is delivery of digital data as a 
processable data file. Such data files can provide the source 
data for multiple data applications, allowing standard and custom 
documents to be created, as well as allowing manipulation of the 
data for annotate/excerpt or update/maintain purposes. The third 
option is interactive access, which provides an agreed-upon 
degree of access to the contractor's CITIS data bases. This 
option can provide the greatest flexibility of use, with 
immediate and timely data access for custom report generation and 
document creation, as well as on-line transactions to request 
transmittal of information, via physical media, as documents or 
processable data files. The following guidelines apply: 


a. If a data product is currently ordered as hard copy, 
consider its digital equivalent, a digital document 
file. 


b. If a source data deliverable is currently ordered, 
consider a processable data file. 

c. If drafts or preliminary data products are currently 
ordered, consider on-line interactive access to 
annotate/excerpt the contractor's file to perform the 
review and provide comments. 

5 . 2 . 4 . 2 . Decision 2 - data form. The next options are the forms 
in which each data deliverable type can be procured. 


5.2.4.2.1. Document. As shown at the top of figure 1, the 
document options are hard copy (e.g., paper and microfilm), or a 
digital document image (e.g., raster) file for printout and 
display. Both of these are static data forms. Application of 
this data is limited to archive, view, or annotate/excerpt only. 
The digital document image file option is more flexible than the 
hard copy option because the data can be more easily stored, 
transported, and managed. Neither hard copy nor dicjital 
documents can be easily modified or updated. 


5.2.4.2.2. Processable data files. As shown in the middle of 
figure 1, the processable data files option provides a dynamic 
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form of the source data with two possibilities: separated files 
for text, graphics, alphanumeric, and audio/visual data; or 
integrated files consolidating the different data representations 
(text, graphics, etc.)* Either can be much more easily 
manipulated and changed by users than can digital document 
images. Text files may contain free-form or structured text, 
depending on users and intended applications. Manuals and 
reports are typical examples of text files. Graphics files may 
contain illustrations, design data, schematics, etc., in vector 
format. 

A technical data product delivered as digital data may contain a 
combination of data types and forms. The technology for 
converting text in hard copy or digital document image form into 
processable data files is rapidly maturing, and is becoming cost 
effective to apply in many applications. The technology for 
converting document graphics into processable data is also 
improving, but it is not yet as capable as the technology for 
text conversion. The choice between processable vector graphics 
and non-processable raster graphics is dependent on the creation 
and application of the data. For example, one alternative for 
creation of a technical manual may be the combination of a 
processable data file of text, together with raster document 
image illustrations. 

Whether processable data files are to be delivered as separate or 
integrated files is largely dependent on technology, the func¬ 
tional application, and the data creation process. Technology to 
enable integration of separate text and graphics data files is 
progressing rapidly. Appropriate data standards are emerging, 
although they are only beginning to enter the commercial market. 

5.2.4.2.3. Interactive access. The options shown at the bottom 
of figure 1 present choices for interactive access into contrac¬ 
tors' CITIS data bases, either by predefined query methods, or by 
more flexible ad hoc queries. Through interactive access, the 
user can tailor presentation of the data to meet the user's 
immediate needs. As the data are needed, they can be accessed in 
their most current authorized version. Although this is the most 
powerful data type, its use is constrained by the cost of 
available technology, and not all contractors have an automated 
data processing infrastructure that provides interactive access 
capability. When interactive access is used, the absence of 
standardized access query tools among many CITIS data bases 
limits the ability to use the ad hoc query form. 

5.2.4.3. Decision 3 - specifications and standards. Relevant 
specifications and standards must be selected to contract for the 
technical and functional aspects of the data. The third column 
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of figure 1 presents available alternatives for the three 
deliverable options. Here, the decision template becomes 
application-specific. In some cases, specifications and stan¬ 
dards apply to a single functional application; MIL-STD-1388-2 is 
a standard that applies only to logistic support analysis 
records, for example. In other cases, a single standard can 
apply to several functional applications; MIL-STD-1840 is a 
standard that defines data organization and file layouts for 
technical manuals, engineering drawings, and other types of 
technical data. 

5.2.4.3.1. Functional and technical standards. In a paper-based 
environment, functional requirements (what data to create) and 
technical requirements (how to organize and format that data in a 
report) were commonly combined in a single document. This 
practice has carried over into automated data processing, but now 
it is gradually being changed. Computer programmers and users 
have both found that separating functional requirements and 
technical requirements into separate standards makes it easier to 
manage changes in technology. Functional specifications and 
standards must be cited to govern the data creation process and, 
within the context of specific applications, determine the data 
contents and structure. Examples of functional specifications 
are MIL-M-38784 for technical manuals and DoD-D-1000 for 
engineering drawings. Technical specifications and standards 
must be cited to govern data structures and foirmats, file 
transfer procedures, interchange requirements, and presentation 
formats. Examples of technical specifications are MIL-M-28001 
for technical manual text and MIL-D-28003 for technical manual 
vector graphics. 

5.2.4.3.2. Predefined and ad hoc queries. Options for interac¬ 
tive access to contractors' data bases are shown at the bottom of 
the third column of figure 1. Distributed relational data base 
technology is so new, and is evolving so rapidly, that CITIS data 
bases usually have unique data organizations and unique access 
methods, depending on what technology the contractor has imple¬ 
mented, and how recently the CITIS architecture was designed.' 
Many different data base management systems, data base query 
languages, and software systems support these access methods. 

The options for interactive access recognize this situation. 
Predefined queries, the first option, retrieve and display 
information from the CITIS using formats that are tailored to a 
specific application and fixed in advance. Some latitude is 
provided by allowing user-defined keys to select, sequence, or 
summarize data. However, the information retrieval requirements 
are well defined in advance, and can be incorporated into the 
CITIS architecture even if this must be done in a CITIS-unique 
manner. The second option for interactive access is the ad hoc 
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query. By definition, an ad hoc query is application- 
independent. Therefore ad hoc query options are driven by 
technology rather than application. This leads to two 
alternatives for ad hoc queries: contractor-unique, and data 
standards. Currently, the unique data access capabilities of 
many contractors' CITIS may require the acquisition manager to 
evaluate a variety of non-standard proposals for ad hoc queries. 
This is the first alternative, but it is not the long-term 
solution. 


5 . 2 . 4 .3.3. Data standards . Data standards, the second 
alternative for ad hoc queries, address emerging technology and 
standards that govern the basic data, independent of their 
creation processes and their internal relationships with each 
subcomponent. These concepts will form the basis for development 
and implementation of longer term CALS capabilities. The goal of 
these data standards is a neutral view of data that is consistent 
for all applications needing the data. When this goal is 
achieved, data definitions, relationships, and rules for consis¬ 
tency and integrity will be controlled by a master data model and 
an active data dictionary, permitting uniform, standard access 
techniques for both computers and computer users. Data access 
methods can then be hardware and software independent, not 
requiring the user to be familiar with multiple, different data 
base access methods. 

5.2.4.4. Decision 4 - digital delivery mods. The final options 
are the delivery modes in which to procure the technical data in 
digital form. The right side of figure 1 presents two alterna¬ 
tives for delivery: physical media and telecommunications. 
Physical media forms for delivery of digital data consist of 
magnetic tape, magnetic disk, and optical disk. Delivery of 
documents or processable data using telecommunications is not the 
same as interactive access, but rather is simply one-way 
electronic mail. Telecommunications delivery alternatives 
involve the selection of high-speed dedicated lines, public or 
private networks such as the Defense Data Network (DDN), or 
satellite links. The best medium of delivery is dependent on an 
analysis of data volumes, urgency, and frequency of use versus 
the cost and security of each delivery medium. With current 
technology, physical media transfer is generally the most cost- 
effective means of transferring large data files. Telecommuni¬ 
cation networks are in increasingly widespread commercial as well 
as DoD use. However, CALS introduces new problems because of the 
volume of digital data that will be transmitted, and associated 
requirements for data protection and integrity. Therefore, 
telecommunications is currently most appropriate for interactive 
access or special low volume use. 
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5.3. Contract deliverables. The contract statement of work 
should task the contractor to prepare a CALS implementation 
strategy, taking into consideration the assumptions and 
constraints established by the acquisition manager. Supported by 
necessary trade studies, this strategy should enumerate and 
describe the framework for CALS implementation activities to be 
accomplished during each phase of weapon system development. It 
should list the technical data that will be acquired in digital 
form, and describes the actions to be taken by the contractor to 
achieve functional process integration. The implementation 
strategy will serve as a guide in developing contract require¬ 
ments in later program development phases. It should be updated 
at the beginning of each program phase to define implementation 
plans for the upcoming phase in greater detail, resolve 
outstanding strategy issues, respond to strategic changes, and 
define appropriate contract language for the upcoming development 
phase. 


5.4. Data protection and integrity, data rights, and related 
issues. 

5.4.1. Industry. Contractors may choose to limit access to data 
documenting products, procedures, and processes for which the 
government or other contractors do not possess the data rights. 

In addition, much of the data documenting weapon systems is 
subject to technology transfer limitations, such as the Arms 
Export Control Act, that impose restrictions on free release of 
such data. Contractors must develop and follow procedures which 
ensure that digital data delivered to, or accessed by, the 
government are properly marked and that controls and safeguards 
in the digital environment provide at least the level of protec¬ 
tion provided in the paper-based environment. Where classified 
information is developed or used by industry, additional 
oversight, programmatic controls, and special handling procedures 
will be imposed by the acquisition manager, who will be supported 
by an extensive community of security organizations. Technology 
and standards are still being developed to address the newly- 
emerging issues associated with data protection and integrity in 
a digital environment. Procedures for ensuring data protection 
and integrity are extensive; selected areas that require review 
during planning for the acquisition of digital information are 
discussed in Appendix E. 

5.4.2. Government. The government must identify during 
acquisition planning the procedures that should be developed for 
effective management of classified, sensitive, or limited rights 
data. Successful implementation will require clear contractual 
agreement on how data will be safeguarded, both by the contractor 
and subsequently by the government. In addition, where govern- 


20 





HIL-EDBK-59 


ment access of a contractor data base is desired, contractors 
will be concerned about government access to data that have not 
been validated by the contractor, data the contains proprietary 
information, and data that is outside the scope of the 
contractual agreement. In such cases the government should 
consider acquiring access to a separate data base of validated 
data that has been delivered in place, until proven procedures 
are developed for managing government access to contractor's data 
systems. 

5.5. Detailed guidance for applications. The preceding section 
provides general guidelines for procurement and integration of 
technical data in weapon system acquisition contracts. The 
transition from paper to digital data deliverables and digital 
data access requires review and revision of traditional ways of 
procuring data, and development of new contractual approaches. 

To aid the acquisition manager in accomplishing the evolutionary 
transition to a contractor/government shared data environment, 
initial CALS attention has been focused on functional areas that 
are large generators or users of technical data. Appendices to 
this handbook are provided for the following topics: 

Appendix A, CALS Overview. 

Appendix B, Application Guidance for Acquisition of Digital 
Deliverables. 

Appendix C, Functional Requirements for Integration of 
Contractor Processes. 

Appendix D, Contract Requirements for Delivery Modes. 

Appendix E, Data Protection and Integrity, Data Rights, and 
Related Issues. 
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6. NOTES 

6.1. Intended use. The purpose of this military handbook is to 
provide weapon system and equipment acquisition managers with 
general information and detailed application guidance for con¬ 
tractually implementing Computer-aided Acquisition and Logistic 
Support (CALS) requirements in weapon system and related major 
equipment procurements. This military handbook also describes 
CALS, aids in the implementation of functional integration 
requirements for contractors, and provides guidance to facilitate 
the generation, access, and delivery of digital technical 
information. 

6.2. Subject term (key word) listing. 

Acquisition management 

CAD 

CAE 

CALS 

CAM 

Computer-aided acquisition and logistic support 

Computer aided design 

Computer aided engineering 

Computer aided manufacturing 

Computer integrated manufacturing 

Computer security 

Contract requirements 

Contractor integrated technical information system 

Concurrent engineering 

Costs and benefits 

Data base management 

Data management 

Data protection and integrity 

Integrated logistic support 

Life cycle 

Logistic support analysis 
Weapon systems 
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CALS OVERVIEW 
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10. SCOPE 

10.1. Purpose. This appendix provides a detailed discussion of 
Computer-aided Acquisition and Logistic Support. 


20. REFERENCED DOCUMENTS 

20.1. Govenment documents. 

20.1.1. Specifications, standards, and handbooks. Unless 
otherwise specified, the following specifications, standards, and 
handbooks of the issue listed in that issue of the Department of 
Defense Index of Specifications and Standards (DoDISS) specified 
in the solicitation form a part of this handbook to the extent 
specified herein. 

SPECIFICATIONS 

MILITARY 

DOD-D-1000 Drawings, Engineering and Associated 

Lists 

MIL-D-5480 Data, Engineering and Technical 

Reproduction, Requirements for 

MIL-D-8510 Drawing, Undimensioned, Reproducibles, 

Photographic and Contact, Preparation of 
(ASG) 

MIL-M-9868 Requirements for Microfilming of 

Engineering Documents, 35mm 

MIL-D-28000 Digital Representation for 

Communications of Product Data: IGES 
Application Subsets 

MIL-M-28001 Markup Requirements and Generic Style 

Specification for Electronic Printed 
Output and Exchange of Text 

MIL-R-28002 Raster Graphics Representation in Binary 

Format, Requirements for 

MIL-D-28003 Digital Representation for Communication 

of Illustration Data: CGM Application 
Profile 
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MIL-M-38761 Microfilm and Microfilm Frame Desk Used 

for Recording Engineering Drawings and 
Associated Data 

MIL-M-38784 Manuals, Technical: General Style and 

Fonnat Requirements 

(Application for copies should be addressed to the Naval Publica¬ 
tions and Forms Center (NPFC), 5801 Tabor Avenue, Philadelphia, 

PA 19120 or Defense Communications Agency, DDN PMO (B613), 
Washington, DC 20305.) 

STANDARDS 

FEDERAL STANDARDS 

FED-STD-1041 (FIPS PUB 100-1) Interface between Data 

Terminal Equipment and Data Circuit- 
Terminating Equipment for Operation with 
Packet-Switching Data Communication 
Networks. (Adoption of CCITT Recommen¬ 
dation X.25). 

FEDERAL INFORMATION PROCESSING STANDARDS 

FIPS PUB 146 Government Open System Interconnection 

Profile (GOSIP) 

(Application for copies should be addressed to the Superintendent 
of Documents, Government Printing Office (GPO), Washington, D.C. 
20402, or the National Technical Information Service (NTIS) 5285 
Port Royal Road, Springfield, VA 22161.) 

MILITARY 


DOD-STD-100 

MIL-STD-188-114 

MIL-STD-470 

MIL-STD-499 

MIL-STD-785 

MIL-STD-804 


Engineering Drawing Practices 

Electrical Characteristics of Digital 
Interface Circuits 

Maintainability Program for Systems and 
Equipment 

Engineering Management 

Reliability Program for Systems and 
Equipment Development and Production 

Formats and Coding of Aperture Cards 


26 







MIL-HDBK-S9 
APPENDIX A 

MIL-STD-1379 Military Training Programs 

MIL-STD-1388-1 Logistic Support Analysis 

MIL-STD-1388-2 DoD Requirements for a Logistic Support 

Analysis Record 

MIL-STD-1777 Internet Protocol Standard 

MIL-STD-1778 Transmission Control Protocol Standard 

MIL-STD-1780 File Transfer Protocol 

MIL-STD-1781 Simple Mail Transfer Protocol 

MIL-STD-1782 TELNET Protocol Specification 

MIL-STD-1840 Automated Interchange of Technical 

Information 

MIL-STD-2165 Testability Program for Electronic 

Systems and Equipments 

HANDBOOKS 

MILITARY 

MIL-HDBK-217 Reliability Prediction of Electronic 

Equipment 

(Application for copies should be addressed to the Naval Publica¬ 
tions and Forms Center (NPFC), 5801 Tabor Avenue, Philadelphia, 

PA 19120 or Defense Communications Agency, DDN PMO (B613), 
Washington, DC 20305.) 

20.1.2. Other government documents. The following government 
documents and publications form a part of this military handbook 
to the extent specified herein. 

FEDERAL 

NSDD 145 National Policy on Telecommunications and 
Automated Information Systems Security 

MILITARY 

DDN X.25 Host Interface Specification, an 

implementation of CCITT Recommendation X.25 
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(Application for copies should be addressed to the Defense 
Communications Agency, ATTN: DDN PMO, Code B600, Washington, DC 
20305.) 

DoD-5200.28-STD DoD Trusted Computer System Evaluation 

Criteria 


D 0 D- 5220 . 22 -M Industrial Security Manual 

NCSC STD-004-85 Guidance for Applying the Department of 

Defense Trusted Computer System 
Evaluation Criteria in Specific 
Environments 


NCSC TG-005 Trusted Network Interpretation of the 

Trusted Computer System Evaluation 
Criteria 


(Application for copies should be made to the Superintendent of 
Documents, U.S. Government Printing Office, Washington, DC 
20402.) 


20.2. Other publications. The following documents form a part 
of this specification to the extent specified herein. The issues 
of the documents that are indicated as DoD adopted shall be the 
issue listed in the current Department of Defense Index of 
Specifications and Standards (DoDISS) and the supplement thereto. 

Electronic Industries Association (EIA) 


EIA RS-232-C Interface between data terminal equipment and 
data communication equipment employing serial 
binary data interchange. 

EIA RS-422-A Electrical Characteristics of Balanced 
Voltage Digital Interface Circuits. 

EIA RS-449 General purpose 37-position and 9-position 

interface for data terminal equipment and 
data circuit-terminating equipment employing 
serial binary data interchange. 


(Application for copies should be addressed to the Electronic 
Industries Association, Standard Sales, 2001 I Street, NW, 
Washington, D.C. 20006.) 
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Network Information Center (NIC) 

Request for Change (RFC) 826 An Ethernet Address Resolution 

Protocol (IP address to media 
access control address 
translation). 

(Application for copies should be addressed to the ARPANET 
Network Information Center; SRI International, Menlo Park, CA 
94025.) 

20.3. Order of precedence. In the event of a conflict between 
the text of this handbook and the references cited herein, the 
text of this handbook shall take precedence. 
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30. DEFINITIONS 

30.1. Acquisition manager. The system/equipment program 
manager, the program manager's staff, and other DoD officials 
responsible for determining contract requirements for the 
generation, acquisition, and use of weapon system/equipment 
technical data, and having acquisition authority for weapon 
systems and equipment. 

30.2. CALS Core Requirement. The set of documents that defines 
the environment necessary for Computer-aided Acquisition and 
Logistic Support (CALS) to function. These documents fall into 
three basic categories: functional standards, technical 
standards, and data standards. 

30.2.1. Functional standard. A document that establishes and 
defines requirements for management, design processes, 
procedures, practices, methods, and data applicable to the 
creation of data products. 

30.2.2. Technical standard. A standard that controls the medium 
or process of exchanging data between a sending and a receiving 
system. Data exchange is defined in terms of presentation 
formats and transformations of those presentation formats. 
Technical standards include document image standards; separate 
graphics, text, and alphanumeric standards; and integrated 
standards. 


30.2.2.1. Docximent image standard. A technical standard 
describing the digital exchange format of a print/display file of 
a report or other document. (CCITT Group 4 and the proposed 
Standard Page Description Language are examples.) 

30.2.2.2. Graphics standard. A technical standard describing 
the digital exchange format of graphics data. (CCITT Group 4 and 
CGM are examples.) 

30.2.2.3. Integrated standard. A technical standard describing 
the exchange format of digital data which integrates text, gra¬ 
phics, alphanumeric, and other types of data in a single 
(compound) file. (ODA/ODIF is an example.) 

30.2.2.4. Text standard. A technical standard describing the 
digital exchange format of textual data. (SGML is an example.) 

30.2.3. Data standard. A specific set of data entities, 
relationships among data entities, and their attributes, often 
expressed in the form of a Data Dictionary and a set of rules 
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that govern data definition, data integrity, and data 
consistency. (The proposed PDES standard is an example.) 

30.3. Information systems. 

30.3.1. Source system. The computer hardware and software that 
will structure technical information for interchange. 

30.3.2. Destination system. The computer hardware and software 
receiving transferred data. 

30.3.3. Government receiving system. The collective term for 
all government agencies and offices responsible for receiving, 
processing, reviewing, or approving technical data ordered on 
government contracts, including the destination system. 

30.3.4. Integrated Weapon System Data Base (IWSDB) . The logical 
collection of shared data for a specific weapon system that 
supports both Contractor Integrated Technical Information System 
(CITIS) and government technical information system users 
throughout the weapon system life cycle. The physical location 
of the data may be distributed among contractor or government 
automated data processing systems. 

30.3.5. Technical information systems. The generic term for the 
enterprise network of existing and augmented automated data 
processing systems used by government and contractors for 
management of technical information in support of the design, 
manufacture, and logistic processes for products such as weapon 
systems and related major equipment items. 

30.3.5.1. Contractor Integrated Technical Information System 
(CITIS) . The collection of automated data processing systems and 
applications used by the co:»tractors (i.e., the prime(s) and all 
subcontractors) to enter, update, manage, retrieve, and 
distribute technical data from a specific Integrated Weapon 
System Data Base. 

30.3.5.2. Government Technical Information Systems . The 
collection of automated data processing systems and applications 
used by government agencies and offices to enter, update, manage, 
retrieve, and distribute technical data from a specific 
Integrated Weapon System Data Base. 

30.4. Technical data. Information including CAD data, CAE data, 
CIM data, configuration management data, group technology data, 
process planning and control data, engineering design data, bill 
of materials data, inventory data, and technical publications 
data. 
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30.4.1. Product data. All data elements necessary to define the 
geometry, the function, and the behavior of a piece part or an 
assembly of parts over its entire lifespan. The term includes 
all product definition data elements as well as additional 
logistics elements for reliability and maintainability. 

30.4.2. Product definition data. The totality of data elements 
required to completely define a product. Product definition data 
include geometry, topology, relationship, tolerances, attributes, 
and features necessary to completely define a component part or 
an assembly of parts for the purposes of design, analysis, 
manufacture, test, and inspection. 

30.4.3. Product data exchange specification (PDES) . Proposed 
standard for communicating a complete product model with 
sufficient information content so as to be interpretable directly 
by advanced CAD/CIM applications such as generative process 
planning and CAD directed inspection. 

30.4.4. Engineering data. Any data, either government, 
contractor, or vendor, that contain authoritative engineering 
definition or guidance on material, items, equipment system 
practices, methods, and processes relating to the design, 
manufacture, acquisition, test, inspection, or maintenance of 
items or services. Engineering data includes the following: 
drawings, associated lists, contractor or vendor specifications, 
standards, documents referenced on drawing lists, revision 
authorization documents, engineering change orders, government or 
industry associated specifications and standards, and other 
related documents. 

30.5. Contract data deliverables and access. 

30.5.1. Document. A set of text or graphics technical data 
organized and formatted for direct human interpretation. A docu¬ 
ment can be delivered as printed pages or digitally in the form 
of composed page images. Technical data supplied in document 
form are not intended for subsequent processing or 
transformation. 

30.5.2. Document Image File. A file of composed page images in 
digital form. Examples are raster image files and page 
description language files. 

30.5.3. Processable Data File. Alphanumeric, text, graphics or 
integrated data files organized and formatted so that an 
automated data processing system can further structure or 
restructure the data in a variety of ways. Unlike document image 
files, processable data files may contain information that is 
directly machine-interpretable. Processable data files provide 
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additional flexibility of use because they consist of the digital 
source data from which documents of varying types can be 
produced. 


30.5.4. Interactive Access. The ability to access authorized 
portions of the source data in a CITIS or government system via 
on-line telecommunications data transfers in real or near-real 
time using various types of queries. Interactive access can be 
used to generate documents, processable data files, or both. 

Data processing categories for interactive access cover the 
entire range from view only to the full capability of down¬ 
loading data for subsequent processing and transformation 
purposes. Interactive access also includes on-line transactions 
which request transmittal of information via physical media as 
documents or processable files. 

30.6. File types. 

30.6.1. Alphanumeric File. A data file containing structured 
numeric or alphanumeric fields. Data base files are alphanumeric 
files. 


30.6.2. Text file. A file which uses the American standard Code 
for Information Interchange (ASCII) or similar system to 
represent the text of a document. Data within a text file are 
delineated as human readable words, sentences, and paragraphs 
rather than data elements. 

30.6.3. Text/Graphics Integration. The necessary indexing and 
linkages between a computer readable text file and computer 
readable graphics file so that they can both be output or updated 
as a single, apparently continuous, file. 

30.7. Acronyms and abbreviations. The acronyms and 
abbreviations used in this military handbook are defined as 
follows: 

ANSI 

ASCII - 
CAD 
CAE 
CALS 

CCITT - 

CD-ROM - 
CDRL 
CGM 
CIM 

CITIS - 
DDN 


American National Standards Institute 
American Standard Code for Information Interchange 
Computer Aided Design 
Computer Aided Engineering 

Computer-aided Acquisition and Logistic Support 
International Consultative Committee on Telegraphy and 
Telephony 

Compact Disk-Read Only Memory 
Contract Data Requirements List 
Computer Graphics Metafile 
Computer Integrated Manufacturing 

Contractor Integrated Technical Information System 
Defense Data Network 
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DID - Data Item Description 

DLA - Defense Logistics Agency 

DoD - Department of Defense 

EDI - Electronic (business) Data Interchange 

FIPS - Federal Information Processing Standard 
GOSIP - Government Open Systems Interconnection Profile 
IGES - Initial Graphics Exchange Specification 
ILS - Integrated Logistic Support 

IP - Internet Protocol 

ISD - Instructional Systems Design 

IWSDB - Integrated Weapon System Data Base 
LAN - Local Area Network 

LSA - Logistic Support Analysis 

LSAR - Logistic Support Analysis Record 

ODA/ODIF - Office Document Architecture / Office Document 
Interchange Format 

OSD - Office of the Secretary of Defense 

OSI - Open Systems Interconnection 

PDES - Product Data Exchange Specification 

PDL “ Page Description Language 

R&M - Reliability and Maintainability 

RFP - Request for Proposal 

SGML - Standard Generalized Markup Language 

SOW - Statement of Work 

SPDL - Standard Page Description Language 
TCP - Transmission Control Protocol 

TDP - Technical Data Package 
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40. OVERVIEW OF COMPUTER-AIDED ACQUISITION AND 
LOGISTIC SUPPORT (CALS) 

40.1. CALS overview. Computer-aided Acquisition and Logistic 
Support (CALS) is a Department of Defense (DoD) and industry 
strategy to facilitate the integration of digital technical 
information for weapon system acquisition, design, manufacture, 
and suppoirt functions. The Deputy Secretary of Defense launched 
the DoD CALS initiative in September 1985 and established a DoD 
Steering Group to oversee its implementation. CALS will provide 
an effective transition from current paper-intensive weapon 
system acquisition and support processes to the efficient use of 
digital technical information. CALS will reduce acquisition and 
operating costs, shorten lead times for acquisition and logistic 
support, and thereby improve military readiness and combat 
effectiveness. 

40.1.1. CALS requirements. Both DoD and industry are investing 
in automation of a variety of functional areas to achieve 
productivity and quality gains. Existing islands of technical 
data automation within DoD, between DoD and industry, and within 
industry must be interfaced and integrated to reduce duplicative 
data generation and maintenance, and to eliminate requirements 
for expensive hard copy output and reentry of data. CALS 
addresses requirements for an orderly transition from a labor and 
paper-intensive environment to the use of digital technical 
information for design, manufacturing, acquisition, and support 
processes. 

40.1.2. CALS strategy. To achieve CALS benefits, a phased CALS 
strategy has been established by a team consisting of Office of 
the Secretary of Defense (OSD), the military departments, the 
Defense Logistics Agency (DLA) and industry. The key elements of 
that strategy are: 

a. Standards and integration requirements. Accelerate the 
development and testing of standards for digital 
technical data interchange and integrated data base 
access. 

b. Weapon system applications. Implement CALS standards 
in weapon system contracts and encourage Industry 
modernization and integration. 

c. Technology development and demonstration. Sponsor the 
development and demonstration of the necessary 
technology for integration of technical data and 
processes in high risk areas. 
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d. DoO systems. Implement CALS standards and integration 
requirements in DoD planning and infrastructure 
modernization programs. Infrastructure is the 
underlying framework of organizations, systems and 
processes within which DoD operates. 

40.2. CALS concepts. The CALS system of systems approach, shown 
in figure 2, consists of these key elements: 

a. Industrial systems (i.e., design, manufacturing, and 
customer support). 

b. Government systems, (i.e., acquisition and logistic 
support). 

c. Interfaces between industry and government. 

d. Interfaces within industry among prime contractors, 
subcontractors, and vendors. 

Information can pass between these systems, in both directions, 
in the form of documents, processable data files, and interactive 
access to data bases. 

40.2.1. CALS standards. Three broad groups of requirements 
documents constitute the CALS interchange standards shown in 
figure 2. They are: 

a. Functional Standards. Military standards, military 
specifications, and Data Item Descriptions (DID's) 
which define functional processes, data requirements, 
data creation procedures, and the content and format of 
data products. 

b. Technical Standards. Federal standards, military 
standards, military specifications, and other relevant 
conventions (including their associated DID's) for the 
management, formatting, and physical media or telecom¬ 
munications exchange of text, graphics, alphanumerics, 
and other forms of digital data. 

c. Data Standards. Data dictionaries that provide rules 
governing data element definitions, data relationships, 
and requirements for data integrity and consistency. 

The standards also include file structure definitions, 
index keys, and other descriptive information needed 
for access to data bases. 


36 




MIL>HDBX-59 
APPENDIX A 




INDUSTRY GOVERNMENT 



FIGURE 2. Digital information exchange. 

40.2.2. Functional integration requirements. A major CALS 
objective is a standardized approach for integrating technical 
data use within a weapon system program. Functional integration 
requirements are contractual tasks to be used in statements of 
work (SOW) or incorporated in functional standards articulating 
the required contractor capabilities for the integration of data 
systems and processes. These requirements specify the 
integration of design, manufacture, and support processes, as 
well as other elements of concurrent engineering, for the 
performance of DoD contracts. They also establish the means by 
which contractors will demonstrate the capability to access and 
share data bases among and between functional areas. These 
functional requirements will eventually be incorporated in 
updates to appropriate military standards and specifications. 

The model SOW language in this handbook is provided for use 
pending these updates. 
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4C.2.3. Contractor Integrated Teclinical Xnforiuation System 
(CITIS). As CALS capabilities evolve, technical data required by 
the government for a single weapon system will be logically 
integrated (not necessarily physically integrated) into tightly 
coupled, controlled, and secure weapon system technical data 
bases, allowing access and transfer of data to those parties with 
proper authorization and need to know. The integrated automated 
data processing systems and applications that are utilized by the 
contractor to enter, update, manage, retrieve, and distribute 
data from technical data bases for a specific weapon system is 
called a Contractor Integrated Technical Information System 
(CITIS). The required functional integration of those contractor 
processes necessary to ensure the security, currency, and 
accuracy of the technical information resident in the weapon 
system technical data bases will be articulated and contractually 
specified as requirements for the contractor's CITIS. In 
addition to requiring integration of the contractor's internal 
data and processes themselves, further integration of internal 
contractor data and processes with the government furnished 
information for each weapon system is essential. 

40.2.4. Government Technical Information Systems. The 

collection of automated data processing systems and applications 
that are utilized by the government to enter, update, manage, 
retrieve, and distribute data from technical data bases for a 
specific weapon system will exist on multiple distributed 
automated data processing systems. It will cross functional 
boundaries and may combine data from more than one DoD component 
to support all requests for data from a single weapon system's 
user community. This degree of interchange and integration will 
require tight control and coordination of the separate physical 
data bases to allow transparent support to the user. The needed 
control and coordination within and among the CITIS and 
government systems supporting a weapon system will be provided by 
a logical data structure called the CALS Integrated Weapon System 
Data Base. 

40.2.5. CITIS and government technical Information system data 
for common items. Technical data for subsystems or components 
with multiple weapon system applications must be available to 
users without unnecessary storage redundancy. Hence, the issues 
of integration and standards for data exchange and access are 
just as applicable horizontally across weapon systems as they are 
vertically within the integrated technical data infrastructure 
for a single weapon system. 

40.2.6. Technical data and business data. CALS deals with 
technical data, which includes CAD/CAE/CIM and configuration 
management data, group technology and process planning/control 
data, engineering design and bill of materials data, inventory 
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data, and technical publications data. Another key aspect of 
information interchange in digital form deals with business 
transactions for ordering, shipping, and making payment for the 
products described by CALS technical data. Business data in 
digital form is addressed by DoD's electronic data interchange 
(EDI) program, which also implements approved national standards 
(ANSI X.12) and reflects a common government and industry 
migration to a digital commercial environment. CALS will develop 
EDI transaction sets for accessing and ordering technical data 
from remote data bases, and for enveloping technical data 
packages and exchanges of technical information within an 
enterprise network. 

40.2.7. Concurrent engineering. Concurrent engineering is a 
systematic approach to creating a product design that considers 
all elements of the product life cycle from conception through 
disposal. In so doing, concurrent engineering simultaneously 
defines the product, its manufacturing processes, and all other 
required life cycle processes, such as logistic support. Concur¬ 
rent engineering is not the arbitrary elimination of a phase of 
the existing, sequential, feed-forward engineering process, but 
rather the co-design of all downstream processes toward a more 
all encompassing, cost effective optimum. Nor does concurrent 
engineering entail simultaneous design of the product and 
execution of the production process, an approach which is 
demonstrably unsound. Concurrent engineering is an integrated 
design approach that takes into account all desired downstream 
characteristics during upstream phases to produce a more robust 
design that is tolerant of manufacturing and use variation, at 
less cost than sequential design. It affects all system 
procurement activities from Milestone 0 (concept definition and 
exploration) to the start of Milestone III (the end of full scale 
development). 

There are three dominant approaches being taken by contractors 
today to implement elements of concurrent engineering: 

a. Engineering process initiatives to improve the 
organizations and procedures used to develop a product, 
such as formation of design teams that include people 
from multiple disciplines. 

b. Computer-based support initiatives such as improvement 
of computer aided design tools, leading to integration 
of various software applications and supporting data. 
This is part of a broader objective to create a data 
object once, and use it as a source for many functions 
and processes, including design synthesis and verifica¬ 
tion, production planning, and logistic support 
planning. 
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c. Use of a variety of formal methods, including the 

application of special purpose tools for design and 
production support. Examples include statistical 
process control, design of experiments, design for 
assembly, and Taguchi quality engineering. 

CALS initiatives to improve technical data creation, management, 
and use provide an enabling environment that will accelerate the 
application of concurrent engineering concepts, and their 
consequent benefits. These benefits include the opportunity for 
significant reductions in product development cycles, a wide 
range of cost savings, and substantial improvements in product 
quality. Specific CALS thrusts, such as integration of 
reliability and maintainability (R&M) with computer aided design 
(CAD) and computer aided engineering (CAE) will directly 
contribute to application of concurrent engineering concepts. 

40.2.8. Integration of R&M with CAD and CAE. Integration of R&M 
with CAD/CAE is a high leverage, high payoff CALS target which 
will provide significant improvements in the inherent reliability 
and maintainability characteristics of a weapon system's design. 
These gains will translate into greater operational 
effectiveness, and will decrease life cycle costs associated with 
the weapon system when deployed. Integration of R&M tools with 
the CAD/CAE process is a contributor to a comprehensive 
concurrent engineering strategy, whose objective is design 
optimization through integration of R&M and other domains within 
a cost effective engineering process. R&M integration with 
CAD/CAE will require changes to conventional post design analysis 
processes. These changes will consist primarily of the 
following: 


a. The development of user-friendly analytical tools that 
are tightly coupled to the product design data base and 
that can be rapidly executed by the designer to provide 
short-cycle feedback about the effectiveness of the 
design approach during the design process itself. 

b. The development of effective means to take advantage of 
lessons learned from prior design experience and field 
use in the form of design rules, expert systems, etc. 

c. The development of fully characterized component 
design, performance, and reliability data in a format 
readily accessible by these automated tools. 

For further details see Appendix C. 
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40.3. CALS implementation. CALS is organized into two 
overlapping phases which are characterized by the application of 
different levels of technology to technical data management, and 
by different degrees of impact on functions and processes allowed 
by this enabling technology. Near term implementation focuses on 
converting current paper flows to digital form while beginning 
the integration process. Longer term implementation focuses on 
replacing the parallel and duplicative requirements imposed by 
various acquisition disciplines and functions (e.g., design 
engineering, configuration management, integrated logistic 
support, test and evaluation, etc.) with requirements to develop 
integrated weapon system data bases that are implemented through 
CITIS and government technical information systems. These CALS 
capabilities will allow technical data sharing at the data base 
level, rather than at the physical file level, with multiple 
formats of the same data from a common, configuration-controlled 
source available to different users. This will include the 
information needed for product design, engineering analysis, 
manufacture, and support, and will facilitate application of a 
comprehensive concurrent engineering strategy by making 
information accessible to a variety of industry and DoD users 
through automated and highly integrated means. However, CALS 
implementation will be characterized by a heterogen'ous, mixed 
mode environment in which initiatives at different levels of 
technology often will be implemented in parallel as evolving, 
capabilities allow. 

40.3.1. Near term CALS capabilities. Initial implementation 
focuses on exploiting current and near-term technology to enhance 
the highest impact acquisition and logistics functions; specifi¬ 
cally, it focuses on: 

a. Engineering drawings and other information used to 
support competitive spares procurement. 

b. Technical manuals and other information used to support 
weapon system maintenance. 

c. Logistic Support Analysis Records (LSAR's) and other 
information used to plan logistic support. 

d. Life cycle configuration management of weapon system 
technical information. 

e. Automated interfaces among R&M data, logistics, system 
engineering, and CAD. 

40.3.1.1. Near term CALS events. In these early implementation 
activities, application of technical standards will permit 
digital data interchange in neutral format within and among DoD 
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components, and between DoD and industry. This interchange of 
technical data without resorting to paper products will result in 
increased accuracy and timeliness of data transfer at lower 
costs. Wherever possible, DoD is adopting approved national and 
international standards rather than creating unique DoD protocols 
to define this interface. From a technical perspective, CALS is 
applicable to equipment items at all levels of indenture, from 
the weapon system and weapon system platform to piece parts. 
However, CALS will find its most productive initial applications 
at the weapon system level, where the contractor and government 
infrastructures to use these technical standards are already in 
place or planned. 

40.3.1.2. Near term CALS mechanisms. The mechanism for 
implementing these near term capabilities is a set of core 
requirements (i.e., sample contract language and technical 
standards) that will be used by the DoD components in near-term 
weapon system and data system acquisitions. The initial 
standards have been coordinated throughout DoD and the defense 
industry, and published as MIL-STD-1840, along with associated 
military specifications. Although it was published before CALS 
was established, MIL-STD-1388-2 is also considered to be one of 
the CALS technical standards. This handbook is a companion 
document to the CALS standards that provides initial CALS 
implementation guidance to the acquisition manager.. 

40.3.1.3. CALS military specifications. CALS technical 
standards are being developed and published incrementally to 
provide additional levels of functionality and technical 
capability. MIL-STD-1840 provides data interchange and file 
management requirements for a family of supporting military 
specifications. The specifications already published include 
MIL-D-28000, MIL-M-28001, MIL-D-28002, and MIL-R-28003 (20.1.1). 
As other CALS military specifications are developed, this 
handbook will be updated to provide necessary application 
guidance. 

40.3.2. Longer term CALS capabilities. While near term CALS 
implementation converts current paper flows to digital flows in a 
file transfer environment, longer term objectives target new 
functional capabilities that will be achieved through redesign, 
integration, and consolidation of the numerous parallel, duplica¬ 
tive processes that have grown up in our current paper-based 
culture. 


40.3.2.1. CALS integrated data bases and processes. CALS will 
exploit the additional emerging power of the computer by 
redesigning data formats and integrating what are now separate 
and often redundant collections of data. These actions will 
fully integrate support into the design process, as well as 
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develop a variety of logistics data products from a design data 
base. This integration will produce large savings in 
productivity and result in improved readiness through much 
improved planning and support. CALS integrated data bases and 
processes will be designed to the extent feasible through 
industry cooperative efforts., because industry must implement 
most of the systems to create this capability. 

40.3.2.2. CALS Integrated Weapon System Data Base (IWSDB) . The 

logical collection of shared data for a specific weapon system 
that is contained within CITIS and government data bases, and is 
used throughout the weapon system life cycle is called an IWSDB. 
The physical location of the data may be distributed among 
contractor or government automated data processing systems. The 
CALS IWSDB structure is evolving and will be the basis for the 
integrated, shared data environment. The CALS IWSDB will provide 
a logical (not physical) collection of shared data to support 
both CITIS and government users throughout the weapon system life 
cycle. The IWSDB will be governed by an active data dictionary 
implemented through standards such as the Information 
Requirements Dictionary System, and will be consistent with CALS 
data standards, including PDES as well as data standards to 
control support data. The data standards will provide data 
element definitions, together with the data relationships and 
rules for data integrity and data consistency required to 
accommodate the changes in user requirements and computer 
technologies that are inevitable throughout the 20 to 40 year 
life of the weapon system. 

40.3.2.3. CALS technology development. CALS must evaluate 
alternative technology approaches before committing to full-scale 
implementation of the IWSDB concept. This is being done through 
a series of technology R&D and demonstration programs that have 
been prioritized to facilitate the transition from interfaced to 
integrated systems and processes. Key development areas include 
advanced product data technology for CAD/CAE/CIM, electronic 
technical manual creation and delivery systems, concurrent 
engineering and integration of R&M with design, and telecommu¬ 
nications/gateway access to parts data bases. 

40.3.2.4. IWSDB mechanisms. As with near term implementation, 
the mechanisms for implementing longer term CALS objectives will 
be a set of core requirements that address the functional and 
technical needs of acquisition managers. The difference will be 
the increasing emphasis on redefinition of functional 
requirements in a concurrent engineering environment, and on the 
application of appropriate supporting technology such as data 
management and access standards. The technology and standards 
for interfacing systems will be necessary but not sufficient for 
implementation of long term CALS objectives, and transition 
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bridges between the capabilities of interfaced and integrated 
systems will be needed. 

40.3.2.5. Long term CALS benefits. Achieving these long term 
CALS objectives will yield the following benefits: 

a. More complete integration than is possible within 
interfaced "stovepipe" systems of contractor design, 
manufacturing, and support data systems based on 
advanced product data models. 

b. Near real-time updates of technical data to match 
weapon system configuration. 

c. On-line access by authorized government users to 
distributed contractor and government data bases. 

d. Data bases owned by DoD, but possessed and maintained 
either by DoD or by contractors. 

e. Automated technical manual and training material 
authoring and delivery. 

f. Automated interfaces of spares procurement with 
flexible manufacturing systems. 

g. Integration of R&M engineering as an on-line part of 
the CAD/CAE design processes. 

h. Application of concurrent engineering strategies and 
programs to optimize product and acquisition process 
design and development. 

40.3.3. CALS implementation schedules. Implementation of CALS 
requirements is technically and economically feasible now. 
Implementation of technology to interface contractor systems with 
government systems is already in process, and will continue into 
the mid-1990's and beyond. Planning and development for system 
integration has commenced; technology R&D activities are already 
underway, and implementation will start in the 1990's. DoD and 
industry will be implementing a mixture of system interfacing and 
system integration initiatives throughout the next decade. 

40.4. CALS management organizations. To achieve these 
objectives, the Office of the Secretary of Defense (OSD) 
established a CALS policy office within the office of the 
Assistant Secretary of Defense (Production and Logistics) to 
develop policy and plans for CALS implementation, develop 
standards and corporate architecture elements, and facilitate 
accelerated implementation within industry. The Services and DLA 
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have also designated CALS offices to meet the program objectives 
identified in table 1. The DoD CALS Steering Group established 
by the Deputy Secretary of Defense provides policy guidance and 
coordinates implementation activities. 


TABLE I. CALS points of contact. 


DEPARTMENT/ 

AGENCY 

ADDRESS 

COMMERCIAL 

AUTOVON 

OSD 

CALS Point of Contact 
DASD(S)CALS 

The Pentagon, Room 2B322 
Washington, DC 20301-8000 

202-697-0051 

227-0051 

ARMY 

CALS Point of Contact 
HQTRS, US Army Material 
Command, ATTN: AMCRE-C 
5001 Eisenhower Avenue 
Alexandria, VA 22333-0001 

703-274-9759 

284-9759 

NAVY 

CALS Point of Contact 202-694-9111 

Naval Supply Systems 

Command, ATTN: PML 5505-T 

Crystal Mall #3, Room 517 

1931 Jefferson Davis Highway 

Arlington, VA 22202 

225-5728 

AIR FORCE 

CALS Point of Contact 
HQTRS, Air Force Systems 
Command, ATTN: PLXC 
Andrews AFB, DC 20334-5000 

301-981-3915 

858-3915 

DEFENSE 

LOGISTICS 

AGENCY 

CALS Point of Contact 703-274-4210 

DLA-Z (DCLSO) or 

6301 Little River Turnpike 

Beauregard Square, Suite 310 

Alexandria, VA 22312 

284-4211 

284-4212 
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THE DEPUTY SECRETARY OF DEFENSE 
WASHINGTON, D.C. 20301 


5 AUG 1988 


MEMORANDUM FOR SECRETARIES OF THE MILITARY DEPARTMENTS 
DIRECTOR, DEFENSE LOGISTICS AGENCY 

SUBJECT: Computer-aided Acquisition and Logistic Support (CALS) 

To achieve productivity and quality improvements, my 
September 1985 letter on CALS set the goal of acquiring technical 
data in digital form (rather than paper) for weapon systems 
entering production in 1990 and beyond. We have now taken a 
major step toward routine contractual implementation. The 
Department of Defense (DoD) has coordinated with industry the 
first in a series of CALS issuances of national and international 
standards for digital data delivery and access. These standards 
have been published in MIL-STD-1840A, "Automated Interchange of 
Technical Information," and supporting military specifications. 

The CALS standards will enable either digital data delivery or 
government access to contractor-maintained technical data bases. 

Effective immediately, plans for new weapon systems and 
related major equipment items should include use of the CALS 
standards. Specifically: 

o For systems now in full-scale development or production, 
program managers shall review specific opportunities for 
cost savings or quality improvements that could result from 
changing weapon system paper deliverables to digital 
delivery or access using the CALS standards. 

o For systems entering development after September 1988, 
acquisition plans, solicitations, and related documents 
should require specific schedule and cost proposals for: 

(1) integration of contractor technical information systems 
and processes, (2) authorized government access to contrac¬ 
tor data bases, and (3) delivery of technical information in 
digital form. These proposals shall be given significant 
weight for their cost and quality implications in source 
selection decisions. The CALS standards shall be applied 
for digital data deliverables. 

DoD components shall program for automated systems to 
receive, store, distribute, and use digital weapon system tech¬ 
nical information, including achieving the earliest possible date 
for digital input to DoD engineering data repositories. These 
systems shall be configured or adapted to support the CALS 


FIGURE 3. CALS implementation requirements. 
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standards. Plans for CALS implementation and productivity 
improvements will be addressed in Defense Acquisition Board and 
Major Automated Information System Review Council acquisition 
reviews, and in corresponding Service and Agency reviews. 

Each application decision shall be made on its own merits 
with respect to the productivity and quality improvements 
expected at either prime contractor or subcontractor level. The 
Under Secretary (Acquisition) will issue further guidance on 
contract requirements, such as CALS options, in invitations for 
bid; opportunities and safeguards for small business and other 
vendors and subcontractors; government and contractor incentives; 
and funding mechanisms for productivity-enhancing investments in 
automation and CALS integration by defense contractors. 

I believe that CALS is one of the most important and far 
reaching acquisition improvements we have undertaken. I would 
appreciate having the Assistant Secretary (Production and 
Logistics) receive your plan of action within 90 days, including 
identification of systems where opportunities exist for cost 
savings or quality improvement through application of CALS 
technology, the investment required to achieve these benefits, 
and proposed schedules for implementation. 


William H. Taft, IV 


cc: Under Secretary of Defense (Acquisition) 

Assistant Secretaries of Defense 


FIGURE 3. CALS Implementation Requirements - Continued. 
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10. SCOPE 

10.1. Applicability. This appendix provides guidance to 
government activities on acquisition of digital deliverables in 
the functional areas that currently produce the greatest volume 
of hard copy technical data. It is applicable to all Department 
of Defense (DoD) components which acquire weapon systems and 
equipment. 

10.2. Purpose. This appendix provides decision guidance and 
model language for tailoring the wording of standard DoD Requests 
for Proposal (RFP's) and Contract Data Requirement Lists (CDRL's) 
to allow and encourage the integrated preparation and submission 
of, or access to, digital data for design, manufacturing, and 
support applications. 


20. REFERENCED DOCUMENTS 

See list of references appearing in Appendix A. 


30. DEFINITIONS 

See list of terms and acronyms appearing in Appendix A. 
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40. GENERAL GUIDANCE 

40.1. Contracting for digital data. A major thrust of the 
Computer-aided Acquisition and Logistic Support (CALS) program is 
delivery of, or access to, weapon system data in digital form. A 
second major thrust is the integration of the data bases which 
produce that data and make it available for use. Implementation 
of these thrusts requires changes to DoD solicitations and 
contracts, including their attachments and enclosures. These 
changes should be made with full consideration of the ability of 
contractors to provide digital data and the ability of government 
activities to make cost effective use of digital data 
deliverables or access. 

40.2. Tailoring and revision of functional standards. Existing 
functional standards may be insufficient to invoke these 
alternatives contractually. Many of these standards were written 
to address not only hard copy delivery requirements, but also 
style and format provisions designed for the paper environment. 
Therefore, tailoring is frequently required when they are cited 
by the contract. In some cases, tailoring out inappropriate 
requirements may be insufficient, and alternative language may be 
needed as part of the statement of work. The acquisition manager 
should identify necessary changes to functional standards and 
forward them to the appropriate preparing activity to facilitate 
revision and publication of updated functional standards. 

40.3. Application of the master decision template. The master 
decision template (Figure 1, 5.2.5) provides guidance for 
analysis of how technical data should be acquired by the 
government from the contractor. This appendix discusses the 
application of the master decision template to specific 
functional areas, including the appropriate technical standards 
and specifications. 

40.3.1. Tailoring to meet program requirements. In each case, 
the master template must be tailored to meet the requirements of 
the functional area. In addition, each weapon system program may 
include unique requirements for which additional program-specific 
tailoring will be needed. Most of the applicable CALS standards 
and specifications contain contract-negotiable options among 
which the acquisition manager must choose to satisfy program- 
specific requirements, including multiple classes or types of 
data formats, and different requirements for interim and final 
deliverables. Consequently, the acquisition manager must apply 
this handbook as a guidance document, not as a rulebook. 
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40.3.1.1. Classes of data. Section 1 (scope) and section 6.2 
(ordering data) of a military specification will list classes 
(types, levels) of data addressed by the specification. Usually, 
the acquisition manager must choose one of these classes based on 
the program's information requirements. For example, MIL-D-28000 
includes several data classes, including Class I for technical 
illustrations. Class II for engineering drawings. Class III for 
electrical and electronic applications, tnd Class IV for 
numerical control machining data. Class I is usually most 
suitable for technical manuals, class II for engineering drawings 
and book form drawings, etc. 

40.3.1.2. Contract negotiedsle options. Section 6.2 (ordering 
data) of a military specification also summarizes other contract- 
negotiable options allowed to be ordered under the specification. 
For example, MIL-M-28001 requires delivery of an SGML-tagged 
source file as a final deliverable. However, it also allows 
delivery of a page description language (PDL) file as an interim 
deliverable or as a second final deliverable. 

40.3.1.3. Data delivery procedures. CALS military 
specifications provide technical requirements for delivery of 
digital data. MIL-STD-1840 provides rules for organizing files 
of digital data (for example, MIL-M-28001 text files and MIL-D- 
28003 graphics files) into a complete data package, such as a 
technical manual in digital form. Therefore, in most cases 
delivery of digital data must be specified in accordance with 
both MIL-STD-1840 and an appropriate military specification. 

40.3.2. Selection of multiple options. The alternatives 
contained in the decision template are not mutually exclusive, 
and are applied individually to each technical data requirement 
within the functional area. For example, the acquisition manager 
may choose digital document image data for preliminary review and 
approval, and processable data files for final deliverables. 
However, early selection (or rejection) of one deliverable option 
may cause that option or other options to be excluded from 
further consideration for deliverables in subsequent program 
phases. For example, an early decision to require technical 
illustrations in raster form may result in creation of data that 
cannot easily be converted to vector form. 

40.3.3. Data item descriptions (DID's). A DID identifies 
specific data requirements, which may include the format of a 
report used to display the data. Most current DID's were 
prepared with only the hard copy (paper, aperture card, etc.) 
document environment in mind. In a CALS environment, two aspects 
of data acquisition must be examined to determine whether 
existing DID's are adequate: the deliverable itself (documents. 
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processable data files, interactive access), and the delivery 
mode (physical media or telecommunications). 

40.3.3.1. Documents and media. If a document is acquired, in 
either hard copy (paper, aperture card, etc.) or digital (raster, 
PDL, etc.) form, then this requirement is not additive to the 
basic set of data requirements and the existing DID can be used 
without revision. Similarly, a new DID is not required when a 
physical media delivery mode is specified, because this 
requirement is not additive to the basic set of data 
requirements. If a telecommunications delivery mode but not 
interactive access is specified (that is, when electronic mail is 
used), a new DID is also not required. 

40.3.3.2. Processable data files. The basic set of data 
requirements does change when processable data files are 
acquired, even though the exact same data elements are included. 
Therefore, new DID's must be prepared for processable data files. 
Until such DID's are widely available, the acquisition manager 
should prepare a program-specific DID and submit it for approval. 
Such program-specific DID's will be the foundation for revising 
the body of current DID's that are available for all acquisition 
programs. 

40.3.3.3. Interactive access. In the case of interactive 
access, the acquisition manager is acquiring a service, not 
merely deliverable documents or data. In this case, the 
requirements will have to be addressed in the contract statement 
of work. In some cases, such as when a contractor is maintaining 
and updating the technical data for government users after its 
original creation, the requirements may be subject to a separate 
contract action. 

40.4. Technology development and insertion. One characteristic 
of CALS system integration initiatives will be application of new 
technology that is currently still in the research and 
development process. However, the technology for interfacing 
systems is also evolving. This is reflected in all aspects of 
technical data delivery and access, and in the telecommunications 
and computer-aided capabilities through which data delivery and 
access is implemented. Data which cannot cost effectively be 
provided through interactive access today will be routinely 
exchanged using this medium in the future. New specifications 
and standards will be developed and implemented to allow digital 
documents and processable data files to be more efficiently 
managed. Computer system vendors will provide more capable 
hardware and software that can integrate processable data files 
through which different forms of data (text, graphics, etc.) are 
treated as a single, compound data structure. Acquisition 
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managers should be alert for opportunities to apply this more 
advanced technology, as well as cautious about premature 
implementation. CITIS and government technical information 
system architectures must plan for technology insertion, and for 
the attendant problems of managing both multiple concurrent 
capabilities (e.g., raster and vector graphics) and multiple 
concurrent technology levels (e.g., untiled and tiled raster). 
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50. DETAILED GUIDANCE 

50.1. Organization of guidance sections. This appendix is 
organized by functional area. Each section can be used 
separately or in combination with others to contract for digital 
CALS data. The functional areas covered in this release of MIL- 
HDBK-59 are: 

a. 50.2 Technical Manuals. 

b. 50.3 Technical Data Packages (including Engineering 

Drawings, Product Specifications and Book Form 
Drawings, and other Technical Data Package 
components). 

c. 50.4 Logistic Support Analysis Records. 

d. 50.5 Training Products. 

Among the functional areas that will be included in future 
releases of MIL-HDBK-59 are: 

a- 50.6 Technical Specifications and Reports. 

b. 50.7 Interactive Maintenance Aids. 


50.2. ACQUISITION OF TECHNICAL MANUALS 

50.2.1. Scope. This section addresses the selection of digital 
data deliverables for technical manuals (technical orders in the 
Air Force). Technical manuals are the operating and maintenance 
instructions for military technicians. They contain a 
combination of textual narrative and illustrative graphic images 
presented in a formal, structured, page-oriented format governed 
by specific functional standards. These manuals have 
traditionally been prepared and delivered in hard copy fora as 
camera-ready copy, which are, in turn, printed in large lots. 

50.2.1.1. Digital data deliverables. The implementation of 
automated data processing technology offers numerous improvement 
opportunities in both preparation of technical manuals, and the 
delivery, storage, distribution, and maintenance of manuals. 
Technical manual data in digital fora can be stored on magnetic 
or optical media, transmitted and shown on computer terminals, 
and printed on demand. Acquiring technical manual deliverables 
in digital fora allows the military user to view required 
information without printing it on paper. Acquiring processable 
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data files provides the opportunity to tailor outputs for 
particular users and uses. Data can be reformatted into step-by- 
step trouble-shooting formats for maintenance personnel, it can 
be adapted to expert system diagnostic programs, or it can be 
used to generate training aids. 

50.2.1.2. Advances in computer capability. Many of today's 
computer systems still manage and interchange textual data 
differently from graphics data, making it difficult to insure 
consistency between the narrative and illustrative materials 
required in technical manuals. Technology and standards (such as 
ODA/ODIF) are being developed and implemented to overcome this 
problem, and will become increasingly available. Contractors 
will implement this technology rapidly, and acquisition managers 
should anticipate improved tools for maintaining and delivering 
technical manual data. 

50.2.1.3. Data sources for technical manuals. The Logistic 
Support Analysis Record (LSAR) consolidates logistics-oriented 
technical information in conjunction with data for the various 
engineering disciplines and Integrated Logistic Support elements 
to reduce redundancy, facilitate timely usage, and enhance 
consistency among data elements and disciplines. The quality and 
productivity of technical manual development is enhanced when the 
LSAR is used as a principal data source for this process. 
Integration of the data bases that produce LSAR task analysis 
(and other) data, technical manuals, and training materials will 
proviae even greater benefits. 

50.2.2. Decision node discussion. Figure 4 applies the master 
Decision Template for Acquisition of Digital Deliverables to 
technical manual deliverables. The following paragraphs discuss 
the required decisions shown in figure 4. 

50.2.2.1. DellverzUsle options - decision #1. Technical manual 
data can be delivered as composed documents or processable files. 
Interactive access to data bases containing technical manual data 
is a future goal. The composed document deliverable option 
offers the least flexibility, even in digital form. It is a 
static, formatted presentation of the manual, which can only be 
arcnived, viewed, and printed after receipt. Processable files, 
on the other hand, offer more robust capabilities. These files 
can be updated or transformed into many different data types. 

With appropriate data processing systems, processable files can 
support creation of job guides, training documents, and eventual 
on-line distribution of selected portions of the data to 
maintenance personnel. 
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FIGURE 4. Decision template for technical manuals. 


50.2.2.1.1. Destination system constraints on form. Processable 
data files are preferable to composed documents, but the presence 
of both text and graphics may cause some difficulty because not 
all presently installed computing equipment and software can 
simultaneously process text with embedded graphics. This issue 
is rapidly disappearing. Nonetheless, during the period of 
intended use, installed hardware and software at both the 
contractor's site (i.e., the source system) and government's site 
(i.e., the destination system) will be the deciding factor as to 
which form the deliverable may take. 

50.2.2.1.2. Interim dual deliverables. Requirements for 
technical manual deliverables may include both composed documents 
in digital form and processable data files. However, until more 
advanced government systems are available, it may be necessary to 
accept, for each deliverable, both one hard copy (paper) 
technical manual for approval and reproduction/distribution, and 
a digital form of that manual for archiving or update and 
maintenance. When the government implements more advanced 


















MIL-HOBK-59 
APPENDIX B 


computer systems, processable technical manual files (with or 
without composed document image files of the technical manual) 
should suffice. Check with the appropriate Service CALS point of 
contact (Appendix A) for up-to-date guidance. 

50.2.2.2. Forms options - decision #2. A technical manual is 
made up of both text (including narrative and tables) and 
graphics. Integrating these elements into a complete technical 
manual, and dealing with user requirements that are different for 
interim review and approval than for final delivery, may require 
more than merely choosing a single optimum form. The acquisition 
manager may have to choose the appropriate forms for multiple 
deliverables (eg, a processable data file that can be updated and 
maintained, plus a document image file that can be displayed and 
printed on demand), or for the elements of a single deliverable 
(eg, processable data files for text, and document image files 
for graphics). 

50.2.2.2.1. Forms options - decision #2 (for composed 
docximents) . As shown at the top left of figure 4, if composed 
documents have been selected at decision #1, the forms for 
technical manual delivery can be either hard copy (paper or 
microfilm) or a digital composed document image file. The 
digital form of this deliverable consists of composed page images 
of the full manual. It offers greater advantages than hard copy 
in storage, distribution, viewing, and printing. It also 
provides slightly more flexibility than hard copy with respect to 
future data uses, although its format will be fixed and 
unyielding. It is a two-dimensional image of each manual page, 
offering no further updating or processing features beyond 
replication. Neither the hard copy nor the digital fonn supports 
update or maintenance except with great difficulty. 

50.2.2.2.2. Forms options - decision #2 (for processeihle files). 

If processable files are selected at decision #1, the forms for 
technical manual delivery can be either one or more sets of text 
and graphics files, or an integrated data file that contains text 
and graphics in a compound data architecture. The use of an 
integrated data file is a future option. At present, a 
processable technical manual file will be comprised of one set of 
files for textual or numeric data and a separate set of files for 
graphic illustrations and drawings. In the future, these same 
text and graphics data will be available as integrated data files 
with configuration management and positioning features. However, 
the technologies to accomplish such integration are just 
beginning to be introduced. 

50.2.2.2.3. Forms option - decision #2 (mixed mode). A 

technical manual typically contains about 60% text and 40% 
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graphics. The graphics may include illustrations imported from a 
design data base, artwork that has been newly created on an 
advanced authoring work station, and illustrations originally 
created on the drafting table that must now be treated as a 
digital image. The text will include both straight narrative and 
tables, and the tables may be so elaborate that it is technically 
easier to construct them as if they were a graphic illustration, 
rather than organized textual information. In cases such as 
this, the digital deliverable may be made up of files of 
processable data (e.g., the text and the graphics imported from 
design) accompanied by composed document image files (e.g., 
illustrations that have been raster scanned from hard copy 
artwork). See the discussion of raster versus vector graphics 
below. 

50.2.2.3. Specification and standard options - decision #3. 

50.2.2.3.1. Decision #3 for composed documents. Technical 

manuals acquired as composed documents may be acquired in the 
form of either camera-ready masters or digital document image 
files. Camera-ready masters should be delivered in accordance 
with MIL-M-38784 or other appropriate MIL-SPECs or MIL-STDs. 
Digital document image files in raster form should be acquired in 
accordance with MIL-R-28002. MIL-R-28002 provides two options: 

Type I (the default option) for untiled raster data, and Type II 
for tiled raster data, for which a new national standard is being 
developed. Storage of document images in a Page Description 
Language (PDL) provides an alternative form which is slightly 
easier to maintain. A PDL file is a program that is executed by 
an interpreter that controls a raster printer or other output 
device. PDL document image files can be acquired as interim 
deliverables, or as final deliverables in addition to (but not in 
place of) processable data files using MIL-STD-1840 and MIL-M- 
28001. However, these are not standardized, for a Standard Page 
Description Language (SPDL) is still being developed. 

50.2.2.3.2. Decision #3 - specificacions and standards for 
graphics. 


50.2.2.3.2.1. Raster versus vector graphics. Graphics data may 
be in either raster or vector formats. Assuming an adequate 
scanning resolution, raster provides nearly exact fidelity for 
illustrations, whereas vector graphics translates data between 
different sending and receiving system native forms. (For 
example, a line expressed as a pair of end points, versus a line 
expressed as an origin, direction, and length.) This can 
introduce errors, even when an intermediate neutral format (the 
standard) is agreed upon. Vector representations are easily 
edited, maintained, and updated, whereas raster representations 
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can be edited only with great difficulty. Vector representations 
also have the advantage of much smaller file size, even when the 
raster bit-map image has been compressed using an algorithm such 
as that specified by MIL-R-28002. Nevertheless, raster graphic 
illustrations are frequently encountered because scanning remains 
the only practical way of converting a legacy of hard copy 
drawings into digital data. Despite the limitations of raster 
data, the practical consecjuence of the hard copy legacy requires 
supporting both raster and vector formats for graphics. Raster 
illustrations belong to the class of document image files 
discussed in the previous paragraph and should be acquired using 
MIL-R-28002. 


50.2.2.3.2.2. Specifications for vector graphics. There are two 
choices of standards to consider for vector graphics: MIL-D- 
28003 for CGM and MIL-D-28000 for IGES. Generally, the Computer 
Graphics Metafile (CGM) is appropriate for graphics in the 
categories of illustrations, charts, etc., while engineering 
drawings and technical illustrations derived from design data are 
the domain of IGES, the Initial Graphics Exchange Specification. 
CGM files are smaller than equivalent IGES files by a factor of 
up to four. For technical manuals, CGM is the preferred option 
but IGES is allowed. Extensions to the standard to allow 
translation of native CAD data into CGM are still being 
developed. If technical manual illustrations are being derived 
directly from design data, then system limitations may constrain 
the choice of delivery standard. In selecting the appropriate 
option, the acquisition manager should recognize the potential 
problems created by multiple translation steps (e.g., unique CAD 
system to IGES to CGM). MIL-D-28003 specifies an Application 

Profile with two options: Level I for publication quality data, 
and Level II for draft quality data. Uncompressed raster data 
can be included in a CGM file, but MIL-D-28003 should only be 
used where the predominate form of the graphics information is 
vector. MIL-D-28000 specifies several subsets of IGES designed 
to meet different application needs. In most cases, when IGES is 
used for technical manual illustrations, the Class I Technical 
Illustration subset is appropriate. In a few cases, program 
requirements may make it appropriate to specify use of the Class 
II Engineering Drawing subset. In either case, data would be 
delivered in either ASCII or compressed ASCII, as specified by 
MIL-D-28000. 


50.2.2.3.3. Decision #3 for processable text. Processable text 
data files should be acquired in accordance with MIL-M-28001, 
which implements the Standard Generalized Markup Language (SGML). 
An SGML Document Type Definition and Output Specification must be 
selected from MIL-M-28001, or created in accordance with the pro- 
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visions of MIL-M-28001, to meet the docvunent structure and format 
requirements of the technical manual. 

50.2.2.4. Digital delivery mode options - decision # 4 . As shown 
at the right side of figure 4, physical media are currently the 
only practical option for the delivery of document image files or 
processable data files. While telecommunications bulk transfer 
of these files may be possible, it is usually not an economical 
option because of the large volume of data contained in these 
files, particularly the raster document image and raster graphics 
files. When interactive access to a contractor's technical 
manual data base becomes a third deliverable option (see left 
side of figure), then telecommunications may be warranted as a 
delivery mode for interim deliverables. In a few cases, 
telecommunications networks are already being used for on-line 
review and approval of technical manuals or portions of manuals. 

50.2.2.4.1. Decision #4 - magnetic tape. As shown at the far 
right of figure 4, the preferred physical media option to use is 
magnetic tape. Standards for tape media are contained in 
Appendix D of this handbook. It is a mature, stable technology 
that is usually available at all sending and destination systems. 

50.2.2.4.2. Decision #4 - optical disk. Optical disk or CD-ROM 
will be alternative physical media option in the future, and are 
generally well suited for data archiving because they can 
accommodate very large volumes of data quite efficiently. 

However, because they are relatively new technologies, optical 
disk and CD-ROM may necessitate new hardware investments by both 
the contractor and the government to accommodate this media, and 
they are not yet standardized. 

50.2.2.5. Digital deliverable sxunmary. Selection of the options 
at each node of the Technical Manuals decision template should be 
aligned to the needs of the organizations responsible for 
technical manual publication and maintenance within each military 
department. However, requirements for interim deliverables that 
are provided only for review and approval (verification) may be 
evaluated differently than are final deliverables. Delivery of 
processable data is less important when the principal 
applications are view and annotate, than when the intended 
applications are update/maintain and process/transform. 
Consequently, document image files may be more appropriate early 
in the life cycle of the program; however, processable data files 
should be the deliverable of choice when the government assumes 
the responsibility for technical manual update and maintenance. 
These files should be usually be delivered on magnetic tape. 
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50.2.2.6. Example > delivery of digital data into the Automated 
Technical Order System (ATOS) . For example, the appropriate 
selection options for technical manuals delivered to the Air 
Force Automated Technical Order System should be processable 
technical manual files composed of: 

a. SGML text files in accordance with MIL--M-28001 and MIL- 
STD-1840. 

b. Raster graphics files in accordance with MIL-R-28002 
Type I and MIL-STD-1840. 

c. Vector graphics files in accordance with MIL-D-28000 
Class I and MIL-STD-1840. 

50.2.3. Decision guidelines. As noted previously, digital 
delivery options for technical manuals are not mutually 
exclusive. There will often be cases when several options will 
be combined for specific deliverables during a weapon system 
acquisition. The decision criteria presented in this handbook 
are intended to aid in selecting the best options. The following 
is guidance for applying the criteria to technical manuals. 

50.2.3.1. Intended data use. The following general guidelines 
are provided: 

a. Select processable files if internal or third party 
update and maintenance is anticipated, document image 
files if no further revision or change is anticipated. 

b. Select processable files if the future creation of 
specialized documents and aids is envisioned. 

c. Select vector graphics files if update and maintenance 
of illustrations and drawings is desired, raster 
graphic files if hard copy illustrations are being 
converted to digital form. 

50.2.3.2. Life cycle phases. The acquisition life cycle phase 
of the weapon system and its technical data is an important 
consideration. The following general guidelines apply: 

Select document image files if a program is in a late 
phase (i.e., full scale development, or production and 
deployment) and large amounts of data already exist in 
hard copy. 


a. 
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b. Select document image files for interim deliverables 
for in-process review prior to assumption of management 
and maintenance responsibility. 

c. Select processable data files for final delivery, when 
maintenance and update responsibility is assiimed by the 
government. 

50.2.3.3. Delivery cost. Costs associated with the delivery 
process are a consideration. The following guideline applies: 

Select tape for delivery of large volximes of digital data. 

50.2.3.4. Available technology. The limitations of the 
government receiving system are a consideration. The following 
guideline applies: 

Select document image files if the receiving system lacks 
update and maintenance capability, processable data files 
for subsequent processing and transformation. 

50.2.4. Contract implementation of digital data delivery. There 
are five basic, yet non-exclusive, digital deliverable alterna¬ 
tives. These are summarized in table II. 


TABLE II. Technical manual forms and standards. 


Deliverable and 
Form 

Preferred 
Delivery Mode 

Implement With 

1. Document Image 

File 

Magnetic Tape 

MIL-R-28002 or MIL- 
M-28001 (PDL only), 
and MIL-STD-1840 

2. Processable Text 
File 

Magnetic Tape 

MIL-M-28001 and 
MIL-STD-1840 

3. Raster Graphics 
File 

Magnetic Tape 

MIL-R-28002 and 
MIL-STD-1840 

4. Vector Graphics 
File-IGES 

Magnetic Tape 

MIL-D-28000 and 
MIL-STD-1840 

5. Vector Graphics 
File-CGM 

Magnetic Tape 

MIL-D-28003 and 
MIL-STD-1840 


50.2.4.1. Digital data deliverables. MIL-M-38784, Technical 
Manuals: General Style and Foirmat Requirements, is commonly used 
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to order technical manuals; other specifications govern specific 
types of manuals, and are often invoked in conjunction with MIL- 
M-38784. When delivery (or access) of technical manuals in 
digital form is planned, all relevant functional standards must 
be reviewed to ensure that they do not specify requirements which 
are incompatible with the applicable CALS standards. 

50.2.4.2. Ordering requirements. In addition, the tailored MIL- 
M-38784 should be referenced in Block 16 of the CDRL (DD Form 
1423) to specify delivery of digital data in accordance with MIL- 
STD-1840. The physical media standards for magnetic tape 
delivery mode shown in Appendix D should also be specified. 


50.3. ACQUISITION OF TECHNICAL DATA PACKAGES (TDP). 

50.3.1. Scope. A technical data package is a technical 
description that is adequate to support acquisition of an item, 
including engineering and production. The technical description 
consists of all applicable technical data, such as engineering 
drawings, associated lists, product and process specifications 
and standards, performance requirements, quality assurance 
provisions, and packaging details. This section addresses 
acquisition of the elements of a TDP. 


50.3.2. ENGINEERING DRAWINGS. 

50.3.2.1. Scope. This section addresses the acquisition 
alternatives for engineering drawings, a major component of 
Technical Data Packages (TDP's). The emphasis is on those 
drawing levels (as defined in DoD-D-1000) that will be used to 
manufacture hardware; Level 2 (production prototype and limited 
production) and Level 3 (production), rather than Level 1 
(conceptual and developmental design). Typically, only Levels 2 
and 3 are delivered to DoD repositories for archiving and 
subsequent application and use. This section, and the section on 
product specifications and book form drawings that follows, 
distinguish between technical data that is primarily graphic with 
associated text annotation, and technical data that contain a 
more proportional mix of graphics and text. 

50.3.2.2. Overview. Engineering drawings are documents that 
disclose directly or by reference, by means of graphic and 
textual information, the physical and functional end-product 
requirements of an item. Geometry, material requirements, and 
process data, along with notational explanations pertaining to 
specific functions and features of the representation, are its 
typical contents. Process and manufacturing engineers interpret 
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the drawings and create additional information on the material 
and physical processes required to fabricate the parts, 
assemblies, or products described by the engineering drawing. In 
addition, machine instructions can be created from the drawing by 
a process engineer to direct the fabrication and inspection 
processes for parts fabricated on computer numerical control and 
automated production machines. 

50.3.2.2.1. Product definition data. An engineering drawing is 
a subset of what CAD users have come to call product definition 
data. Product definition data includes the information needed 
for design, analysis, manufacture, test, and inspection (see the 
definitions in Appendix A, Section 30). Product definition data, 
in turn, is a subset of product data, which adds the elements - f 
life cycle support to those of design and manufacture. Even 
though an engineering drawing does not contain all product 
definition data, let alone all product data, it is the accepted 
form in which product design information is communicated and 
documented for the record in a hard copy environment. It will 
continue the serve this same function while users transition into 
a CIM environment. 

50.3.2.2.2. Drawing conventions and standards. Because 
engineering drawings meet a wide scope of information and user 
needs, conventions and standards governing their creation have 
been developed to ensure consistency of creation and 
interpretation. These requirements have been codified in a 
hierarchy of military standards and specifications, with DoD-D- 
1000 and DoD-STD-100 at the apex. 

50.3.2.2.3. Evolving technology for engineering drawing data. 

Some design work is still being done on the drafting table, but 
users are increasingly adopting computer aided design (CAD) 
technology. Regardless of how the engineering data is created, 
however, it can still be exchanged between users in either hard 
copy or digital form. 

50.3.2.2.4. Use of raster graphics. DoD stores over 200 million 
engineering drawings and specifications in its repositories, and 
most of this information is duplicated in the repositories of the 
defense contractors who created the drawings. The storage of 
engineering drawings and the generation of spares reprocurement 
packages has become increasingly difficult and time consuming as 
the volume of hard copy data in DoD repositories has continued to 
expand. Thirty years ago, engineering drawing users transitioned 
from paper/vellum to aperture cards as the medium of interchange 
for drawings. Now that new technology is available, and storage 
of erigineering drawings on aperture cards can no longer keep up 
with user needs, the Services' data repositories have initiated 
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the process of raster scanning hard copy engineering drawings for 
more compact storage on optical disk. While this adds no 
intelligence to the engineering data itself, it does 
significantly improve data management capabilities. 

50.3.2.2.5. Computer aided design (CAD). Defense contractors 
are expanding the use of CAD and computer integrated 
manufacturing (CIM) systems to automate design and manufacturing 
functions. These CAD and CIM systems create and use vector 
graphics files, defining the geometry and associated data 
attributes of weapon system assemblies and components. This 
technology facilitates use of other automated tools, such as 
those for reliability and maintainability (R&M) analysis, in the 
design process. PDES, an evolving DoD and industry-supported 
data standard for description of the product over its life cycle, 
will provide additional functionality when it becomes available. 
PDES used with CIM technology will facilitate the integration of 
engineering design, manufacturing, logistic support, and 
configuration management data. Engineering drawings, an output 
of the engineering design process, will be able to be extracted 
directly from product data, largely without intermediate manual 
processes. Ultimately, engineering drawings may no longer be 
necessary for spares reprocurement, particularly when PDES 
product data can be directly transferred between CIM systems. 

50.3.2.3. Decision node discussion. The master Decision 
Template for Acquisition of Digital Deliverables is applied to 
the Engineering Drawings Application as shown in figure 5. Each 
decision is discussed in the following text. 

50.3.2.3.1. Deliverable options - decision #1. The first column 
lists the first set of deliverable options for engineering 
drawings. The current choices are engineering drawing images or 
the more comprehensive product definition data files used by some 
contractors. Interactive access to engineering design data bases 
is a future goal. 

50.3.2.3.2. Form options - decision #2. 

50.3.2.3.2.1. Forms options - decision #2 (for engineering 
drawing images). The deliverable form options for engineering 
drawing images are hard copy and raster image files. Paper, 
vellum, mylar, roll microfilm, and aperture cards are some 
examples of the media used for hard copy. The aperture card has 
become the accepted medium for accpiiring reproducible hard copy 
images of engineering drawings, although other forms are still in 
use. Aperture cards or other hard copy forms delivered to DoD 
automated engineering data repositories will be converted to 
raster images for storage. This conversion can be avoided by 
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choosing delivery of a raster image file. Raster image files are 
the representation of digitally scanned paper drawings or 
aperture cards. There is no intelligence in the raster image 
file. Human interpretation is required, as it is with paper 
drawings or aperture cards. Raster image files are primarily 
useful for data that are to be used in a print on demand, hard 
copy (paper or aperture card) mode. 


Decision «1 

Deliverable 


Decision #2 

Form 
Hard Copy 


Decision #3 
Specs & 

OoD-STD-100/ 

MIL-M-804 


Decision #4 
Delivery 
Mode 





Magnetic Tape 


Physical Media 




Optical Disk 


Telecommunications 




Legend: 


Current 

Future 


FIGURE 5. Decision template for engineering drawings. 

50.3.2.3.2.2. Forms options - decision #2 (for product 
definition data files). The options for product data definition 
files are the CAD data file and the integrated product data file. 
The CAD data file consists of vector data with geometrically 
accurate and precise representations of the product, together 
with associated annotations (dimensions, tolerances, etc.). This 
CAD data can be either two-dimensional or three-dimensional, 
although the CALS standard (MIL-D-28000) described below defines 
a three-dimensional CAD data file. CAD data contains limited 
intelligence, and is suitable for automated interrogation and 
manipulation, such as alternate views of the object or path 
generation for numerically controlled manufacturing machinery. 

DoD repositories plan to accept digital data created by CAD 
systems as input, although in the near term the principal output 
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medium from those repositories will be hard copy or raster 
images. The integrated product data file will contain more 
information. It will include three dimensional features, solids 
modeling, parametric design, material specifications, design 
tradeoffs, process and manufacturing engineering, and machine 
instructions for automated parts manufacturing. This option 
requires technologies that are not yet fully developed or in 
widespread use, and for which standards are still under 
development. 


50.3.2.3.3. Specifications and standards options - decision #3. 
DoD-STD-100 and DoD-D-1000 are the functional standards 
controlling the subject matter and content requirements of 
engineering drawings. Changes to these functional standards, or 
new standards, may need to be developed if current or future CAD 
technology leads to changes in the subject matter or content of 
engineering drawings. Technical specifications and standards are 
well defined for aperture cards, raster image files, and CAD data 
files. 


50.3.2.3.3.1. Specifications and standards options •> decision #3 
(for engineering drawing images). Aperture cards are governed by 
MIL-M-38761 and MIL-STD-804 (hollerith data) requirements. MIL- 
M-9868 governs the microfilming of engineering documents. Raster 
image files are governed by MIL-R-28002. The default format for 
delivery of raster data is MIL-R-28002 Type I (untiled). 

However, MIL-R-28002 Type II (tiled) may be negotiated if the 
appropriate sending and receiving system capability is in place. 

50.3.2.3.3.2. Specifications and standards options - decision #3 
(for product definition data files). CAD data files are governed 
by MIL-D-28000 (IGES). In most cases, the MIL-D-28000 Class II 
subset (engineering drawings) is appropriate. For electrical and 
electronic applications, the MIL-D-28000 Class III subset may be 
more appropriate. Specialized data requirements (which 
technically are not engineering drawings) should be met with 
other IGES subsets (eg. Class IV for numerical control data). In 
either case, data would be delivered in either ASCII or 
compressed ASCII, as specified by MIL-D-28000. The PDES standard 
(when available) for the integrated product definition data file 
should be considered for future deliverables from programs that 
are in the very early phases of concept development. However, 
use of PDES will offer the opportunity to acquire information 
that exceeds the current scope of engineering drawings, and may 
require development of new functional standards, or changes to 
DoD-STD-100 and DoD-D-1000. 

50.3.2.3.4. Digital delivery mode options - decision #4. The 

digital delivery mode options are shown at the right side of 
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figure 5. Physical media is currently the only practical option 
for the delivery of raster image files. Telecommunications bulk 
transfer is possible; however, it is not the preferred method due 
to cost considerations. Future interactive access to the 
contractor's data base will present the option to access specific 
portions of the data as appropriate and, at that time, 
telecommunications may be a viable option for certain interim 
deliverables. An alternative may be to use interactive access to 
locate and order data that is subsequently delivered using 
physical media. The preferred physical media option to use at 
this time is magnetic tape. Reference the tape media standards 
discussed in Appendix D of this handbook. 

50.3.2.3.4.1. Decision #4 - magnetic tape. Magnetic tape is the 
preferred physical medium for delivery. It is a mature, stable 
technology that is usually available at all sending and 
destination systems. 

50.3.2.3.4.2. Decision #4 - optical disk. Optical disk will be 
a future alternate physical media due to emerging standards and 
the increasing nvimber of DoD programs using optical disk 
technology. The major optical disk advantage is its ability to 
archive and store large volumes of data. 

50.3.2.3.5. Digital deliverable summary. In general, the 
evaluation and selection of options at each decision node of the 
Engineering Drawings decision template must be aligned to the 
capabilities of the automated engineering data repository systems 
of the using Military Department. Raster image files should be 
acquired early in the life cycle of the program, when the 
principal application is review and approval. CAD data files 
could be the final deliverables of choice for drawings obtained 
for spares reprocuremc. t technical data packages if the data were 
originally developed on CAD systems. 

50.3.2.3.6. Example - delivery of digital data to DoD 
engineering data repositories. For example, the appropriate 
selection of options for engineering drawings delivered to the 
Army Digital Storage and Retrieval of Engineering Data System 
(DSREDS), the Air Force Engineering Data Computer Assisted 
Retrieval System (EDCARS), or the Navy/Defense Logistics Agency 
Engineering Data Management Information and Control System 
(EDMICS) should be as follows: 

a. Raster image files delivered on magnetic tape in 

accordance with MIL-STD-1840 and MIL-R-28002 Type I. 

b. CAD data files in IGES delivered on magnetic tape in 

accordance with MIL-STD-1840 and MIL-D-28000 Class II. 
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50.3.2.4. Decision guidelines. Digital deliverable options for 
engineering drawings are not mutually exclusive. There will 
often be cases when several options will be combined for specific 
deliverables during a weapon system acquisition. 

50.3.2.4.1. Intended data use. To help evaluate the various 
option combinations, the following guidelines are provided: 

a. Select raster image files for archiving and print-on- 
demand requirements. 

b. Select IGES data files for subsequent input to 
government or industry CAD systems or to CIM systems for 
manufacture of spares. 

50.3.2.4.2. Life cycle phases. To help evaluate the various 
option combinations, the following guidelines are provided: 

a. Select raster image files for early phases with low 
volumes or frequent anticipated design changes, except when 
the drawings submitted for design approval are to undergo 
data processing analysis by the government. 

b. Select raster image files in later phases if early 
phase engineering drawings were paper-based. 

c. Select IGES data files in later phases if the data are 
to be input to CAD/CIM systems for modification or spares 
manufacture. 

50.3.2.4.3. Delivery cost. To help evaluate the various option 
combinations, the following guideline is provided: 

Select magnetic tape for delivery of large volumes of 
engineering drawing data. 

50.3.2.4.4. AvaileUale technology. The following guideline 
applies: 

Select IGES data files if the engineering drawings were 
created on contractor CAD systems. 

50.3.2.5. Contract Implementation for digital data. The prior 
discussion of nodes on the Decision Template for Engineering 
Drawings indicated that there were two basic, yet non-exclusive, 
digital deliverable alternatives, as listed in table III. 

50.3.2.5.1. Digital data deliverables. For both alternatives in 
table III, DoD-STD-100 is insufficient to describe the 
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TABLE III. Summary of engineering drawing forms and standards. 


Deliverable and 

Form 

Preferred 
Delivery Mode 

Implement With 

1. Raster Image File 

Magnetic Tape 

MIL-R-28002 ref.by 



MIL-STD-1840 

2. CAD Data File 

Magnetic Tape 

MIL-D-28000 ref.by 



MIL-STD-1840 


appropriate methods to contractually invoke these alternatives. 
Therefore, the following changes to DoD-STD-100 have been 
submitted for review, coordination, and publication: 

a. Add paragraphs 101.1.2; 101.1.4; 104.3; and 106.1.1 as 
follows: 

101.1.2 Raster/Vector (SELECT RASTER FOR RASTER IMAGE FILE. 
SELECT VECTOR FOR CAD DATA FILE.) Drawing Format. The sheet 
layout, border, title block, revision block, and other 
conventions of engineering drawing format including 
definition and use of explicit scaling factors shall be 
integral to the raster/vector (REPEAT SELECTION AS ABOVE.) 
data file. 

101.1.4 Layer or level conventions. The file layer or level 
conventions shall be identified for all data residing in the 
digital data file. 

104.3 Raster/Vector (SELECT RASTER FOR RASTER IMAGE FILE. 
SELECT VECTOR FOR CAD DATA FILE.) Digital Data Originals. 
Raster/Vector (REPEAT SELECTION AS ABOVE.) digital data 
originals must be verified to ensure the validity of the 
data format contained in the data file. 

106.1.1 Scale of digital data. The digital data base should 
represent an object or assembly at full scale to ensure the 
shareability of represented data. The visual or reproducible 
image should be at a scale appropriate for human 
understanding. 

b. Add sentence to the end of paragraph 201.1.1, as 
follows: 
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Engineering drawings prepared by the use of a CAD system 
shall conform to figures 200-1 through 200-41, unless 
otherwise instructed by the contracting officer. 

c. Add note to paragraph 502.1, as follows: 

Note: Revisions made to the digital data base should 
accurately and precisely represent the change in dimensions 
to the geometry of the object or assembly to ensure the 
shareability of the represented data. 

d. Add paragraph 503.7, as follows: 

503.7 Identifying location of revisions on digital data 
images. All changes made to digital data bases must be 
identified explicitly on their visual output. 

Pending publication, these additional requirements should be 
included in the statement of work, or in Block 16 of the CDRL (DD 
Form 1423) to specify delivery of digital data in accordance with 
MIL-STD-1840. The physical media standards for magnetic tape 
delivery mode (shown in Appendix D) should also be specified. 


50.3.3. PRODUCT SPECIFICATIONS AND BOOK FORM DRAWINGS. 

50.3.3.1. Scope. Product specifications and book form drawings 
provide information such as material content, manufacturing and 
treatment processes, inspection and testing procedures, 
performance requirements, etc, needed for the acquisition of the 
drawing item. This information is an essential element of the 
product definition data set. It is characterized by a mix of 
approximately equal amounts of graphics and supporting narrative 
text. Specifications and book form drawings applicable to an 
item are referenced on the engineering drawing of that item. 
Additionally, a referenced specification or book form drawing may 
itself reference related specifications and book form drawings, 
creating a hierarchy of referenced information, all of which are 
required to fully describe the item. 

50.3.3.2. Purpose. This section identifies the options for 
delivery of product specifications and book form drawings. The 
options selected for delivery of specifications and book form 
drawings are not necessarily the same as for engineering 
drawings. However, these information products are usually 
created, processed, and used in conjunction with one another. 
Consequently, when selecting the delivery option for 
specifications and book form drawings, the delivery option for 
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the engineering drawings should be taken into consideration tor 
technical data package (TDP) consistency. 

50.3.3.3. Decision option discussion. Figure 6 shows the Master 
Decision Template for Acquisition of Digital Deliverables as 
applied to the specifications and book form drawing portion of a 
TDP. The alternatives presented, while not exclusive, must be 
considered and applied in context of the complete TDP and not the 
individual elements of a TDP. 


Decision #1 Decision #2 Decision #3 

Specs & 

Deliverable Form Standarde 


Hard Copy DoD-STD-100 



Decision #4 
Delivery 
Mode 




Magnetic Tape 


Physical Media 


y 

. Optical Disk 


Telecommunications 


Interactive 

Access 


Legend; 

-Current 

. Future 


FIGURE 6. Decision template for product specifications and book 
form drawings. 

50.3.3.3.1. Deliverable options - decision #1. The 

specifications and book form drawings portion of the TDP can be 
delivered as documents or as processable data files. Interactive 
access to engineering design data bases containing product 
specifications and book form drawings is a future goal. The 
document deliverable option offers the least flexibility, even 
when provided in digital form. Documents are static, formatted 
presentations of information which can only be archived, viewed, 
and printed after receipt. Processable data files, on the other 
hand, offer greater capabilities; these files can be updated or 
transformed into many different document types. Delivery of 
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specifications and book form drawings as processable text and CAD 
data files is both preferable and technically feasible. Source 
data can be created by electronic publishing systems (text) and 
CAD systems (graphics). However, the government data processing 
infrastructure to permit acceptance and utilization of the 
information in this form are not yet available in DoD. 

Therefore, the deliverable option for the specifications and book 
form drawings portion of the TDP is effectively limited to the 
docviment category at present. 

50.3.3.3.2. Form options • decision #2. For documents, the 
options are either hard copy (paper or aperture cards), or 
digital raster images. While the hard copy option includes 
paper, the usual procedure is to deliver documents in the same 
aperture card form as for engineering drawings. The digital 
option is limited to raster image data because the PDL 
alternative has not been developed for specifications and book 
form drawings as it has been for technical manuals. As shown in 
figure 6, certain types of processable data files are technically 
feasible, although not yet available because of receiving system 
limitations. When implemented, these options will include 
delivery of product specifications and book form drawings as 
processable text and graphics files, and ultimately integrated 
data files containing both text and graphics. Delivery of a 
combination of raster image text and CAD data files is also 
technically feasible. However, this imposes an additional layer 
of processing complexity on the sending system, and is not 
considered a practical alternative. 

50.3.3.3.3. Specifications and standards option - decision #3. 

Since the processable data file option cannot currently be 
supported by DoD receiving systems, the relevant standards for 
that option will not be discussed, although they are listed in 
figure 6. (See the discussion of specifications and standards 
for technical manuals and engineering drawings for additional 
information.) For deliverable documents, aperture cards are the 
predominant medium for capturing hard copy images of the 
specifications and book form drawings portion of a TDP. 
Specifications and standards governing hard copy preparation are 
DOD-STD-100, DOD-D-1000, MIL-STD'804, MIL-D-5480, MIL-M-38761, 
MIL-D-8510 and MIL-M-9868. MIL-R-28002 governs delivery of 

raster image files; the default form is Type I (untiled raster), 
with Type II (tiled raster) available to meet specific contract 
requirements. It is extremely unlikely that program needs would 
dictate a different raster type selection for specifications and 
book form drawings than is made for engineering drawings. 

50.3.3.3.4. Digital delivery mode options - decision # 4 . The 

delivery mode for specifications and book form drawings as 
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documents (raster image files) may be either physical media or 
telecommunications. However, because of cost considerations, the 
delivery of raster image files using telecommunications bulk 
transfer conventions is not recommended. Of the physical media 
options shown at decision #4, magnetic tape is currently the 
preferred alternative. As with engineering drawings, optical 
disk provides a desirable future delivery mode option, although 
it is not yet widely available or standardized. See Appendix D 
of this handbook for the applicable tape media standards. 

50.3.3.3.5. Digital daliverabla summary. In general, the 
evaluation and selection of the options at each decision node of 
the specifications and book form drawings decision template must 
be aligned to the capabilities of the automated engineering data 
repository systems of the using Military Department. Selections 
should be consistent with those made for engineering drawings 
unless there is a specific reason for making different choices. 

50.3.3.4. Decision guidelines. In general, the options selected 
for delivery of specifications and book form drawings in digital 
form are closely tied to the options selected for the associated 
engineering drawings in the TDP. As with the drawings, it is 
likely that no single option may apply to all specifications and 
book form drawings data. Finally, the delivery options selected 
for the specifications and book form drawings portion of the TDP 
must be compatible with the receiving system capabilities. The 
following guidelines are provided to assist in the option 
selection process. 

50.3.3.4.1. Intended data use. The following general guideline 
is provided: 

Select raster image files for archiving and print on demand 
requirements. 

50.3.3.4.2. Delivery cost. The following general guideline is 
provided: 

Select magnetic tape delivery for delivery of large volumes 
of specifications and book form drawings. 

50.3.3.4.3. Available technology. The following general 
guideline is provided: 

Select raster image files until destination system 
technology allows delivery of specifications and book form 
drawings as processable data files. 
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50.3.4. OTHER TDP COMPONENTS (RESERVED). 

(This section will provide a decision template and supporting 
rationale for the acquisition in digital form of other elements 
of a technical data package. The CALS Industry Working Group on 
Spares Acquisition is defining those elements and the results 
will appear in a future update to this handbook.) 


50.4. ACQUISITION OF LOGISTIC SUPPORT ANALYSIS RECORDS (LSAR). 

50.4.1. Scope. This section addresses the acquisition 
alternatives of LSAR data. Logistic Support Analysis (LSA) 
builds upon data from related systems engineering and design 
analyses, and produces a consolidated and integrated set of 
logistics-related technical data. The resulting Logistic Support 
Analysis Record (LSAR) is a logically integrated data base 
consisting of both the engineering source data upon which 
analysis tasks are based, and the analysis results. With the 
exception of very small programs, documentation of the LSAR is 
accomplished using automated LSAR systems. MIL-STD-1388-2 
defines the format and content of the LSAR and the structure of 
various standard reports that allow delivery of the data rn 
digital form. It also defines LSAR system processing 
requirements and encourages additional LSAR system development. 

50.4.1.1. LSAR data elements. MIL-STD-1388-2 defines the total 
set of data elements that could make up an LSAR data base. The 
acquisition manager must tailor application of the standard to 
weapon system program requirements by selecting the subset of 
data elements actually required. This is done by incorporating 
in the contract DD Forms 1949-1 and 1949-2 listing the specific 
LSAR data that the contractor must generate and provide (through 
access or delivery) to the government. Some data elements (such 
as LSA control numbers) are required because they are keys to the 
data base organization. However, few weapon system programs 
require all LSAR data elements. 

50.4.1.2. Joint service LSAR data system. A baseline LSAR 
system, the Joint Service LSAR Automated Data Processing System, 
has been developed as one alternative for LSA automation. This 
batch mode, flat file system is capable of satisfying the 
requirements of MIL-STD-1388-2, but it lacks many desirable 
features and capabilities afforded by current technology. Many 
contractors have augmented the joint service system by adding 
front-end software to improve data entry efficiency. Others have 
used data base management software to make the data accessible to 
both on-line inquiries and various LSA software tools. Finally, 
some contractors have linked software tools for other 
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engineering, design, and Integrated Logistic Support (ILS) 
functions to the LSAR to use or update LSAR data. DoD is 
currently revising the Joint service LSAR data system to 
implement relational data base technology. 

50.4.1.3. Flexibility of the LSAR. Because of the range of data 
that can be docvimented in an LSAR, the LSAR is able to satisfy 
the data requirements of a number of the deliverables commonly 
appearing on a Contract Data Requirements List (CDRL), such as 
Provisioning Lists and Failure Modes, Effects, and Criticality 
Analysis reports. When these deliverables are submitted to the 
government as processable data files, or when direct access to 
the data base is provided, improvements in data accuracy and 
integrity usually result. Since the LSAR is already a logically 
integrated data base, it invites the use of other software tools 
and linkage with related engineering data bases. Furthermore, 
cost and time savings in data review or receipt of deliverables 
can also be achieved. During the initial acquisition contract, 
the most cost effective means of LSAR data access or delivery 
should be evaluated to enable the contractor to offer as part of 
the subsequent phase proposal one or more digital means of data 
delivery or access. 

50.4.1.4. Relationship of standards for LSAR to other CALS stan¬ 
dards. Two functional standards govern LSA and the LSAR. MIL- 
STD-1388-1 defines the LSA process, as a result of which LSA data 
is created. MIL-STD-1388-2 defines the requirements for the 
LSAR, through which much of that data is assembled, managed, and 
reported. MIL-STD-1388-2 is also a technical standard for 
delivery of LSAR data in digital form. Because it serves as both 
a functional and a technical standard, it is unnecessary (and 
incorrect) to use MIL-STD-1840 to define requirements for 
delivery of LSAR data in digital form. Future revisions might 
separate MIL-STD-1388-2's functional standard role from its 
technical standard role, if such a separation appeared to serve a 
practical purpose. At this time, it does not appear that this 
would be the case. 

50.4.2. Decision option discussion. The master Decision 
Template for Acquisition of Digital Deliverables as applied to 
the LSAR is displayed in figure 7. 

50.4.2.1. DeliveriUsle options - decision #1. LSAR data can be 
delivered as LSAR reports, LSAR data files, or through 
interactive access to a contractor LSA data base. All three 
options either encourage or require a contractor automated LSAR. 
The requirements for LSAR final deliverables will likely be a 
combination of at least two of these options. 
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50.4.2.1.1. Deliverable options *• decision #1 (for LSAR 
reports). The LSAR reports option includes the reports 
identified in Appendix B of MIL-STD-1388-2, plus any 
contractually-required, project-unique reports that can be 
produced using LSAR data. Most reports allow refinement or focus 
for a specific user by tailoring or reformatting. Many of the 
reports were designed as analysis and data review tools and are 
not intended to be deliverable products. LSAR reports are static 
presentations of LSAR data and cannot be updated or processed 
further after delivery. They offer the least flexibility for 
LSAR data use. Therefore, requiring LSAR reports as a deliverable 
option is appropriate only for one-time deliveries or when no 
further processing capability is available. 


Decision #1 
Deliverable 


Decision «2 

Fgrm 

Hard Copy 


Decision #3 
Specs & 
Standards 

MIL-STD-1388-2 


Decision #4 
Delivery 
Mode 



FIGURE 7. Decision template for logistic support analysis 
records (LSAR). 

50.4.2.1.2. Deliverzdsle options - decision #1 (for LSAR data 
files). LSAR data files, the second option, includes the three 
LSAR master files defined in MIL-STD-1388-2, and other LSAR data 
files that require processing after delivery (such as input files 
for Provisioning, Defense Logistics Services Center (DLSC) 
Screening, or Packaging Systems, among others). An internal data 
processing capability is required for each LSAR data file. 
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Delivery of the LSAR master files provides the capability to 
subsequently produce any of the LSAR reports and other data files 
that the LSAR data base was designed to support, and provides 
historical baseline data for weapon system/equipment. Separate 
delivery of other LSAR data files places responsibility for their 
generation with the contractor rather than the government. 

Because of the flexibility provided by these processable data 
files, they can be used to satisfy both interim and final LSAR 
delivery requirements. Periodic delivery can reduce time spent 
for on-site data reviews by providing a vehicle for advanced 
review of the data. Final contract deliverables can be 
consolidated and reduced by internal processing of LSAR data 
files, in part or in total. 

50.4.2.1.3. Deliverable options - decision #l (for interactive 
access). The third LSAR deliverable option is interactive access 
to a contractor's LSA data base. Interactive access includes the 
ability to selectively retrieve, review and print, and process 
contractor LSA source data. Interactive access for faster 
government review of LSAR information represents more of a 
contractor service capability than a specific deliverable 
requirement. This capability makes the most current authorized 
data available to the government and eliminates the time required 
for preparation and submission of deliverable products. It can 
also significantly reduce the time requirement for on-site 
reviews, while supporting internal analyses and planning that 
requires up-tc-date supportability information. Interactive 
access provides the greatest flexibility for using LSAR data, 
either by utilizing the contractor's automated LSAR capabilities 
or by electronically transferring the data for further internal 
processing. Since interactive access can support interim and 
final delivery of both LSAR reports and data files, it may 
entirely eliminate the need to bring the LSAR data in-house. 
(However, it is advisable to have LSAR master files delivered at 
contract completion.) The interactive access service can be very 
effective for satisfying LSAR deliverable requirements during the 
early life cycle phases when the volume of LSAR is low. In 
latter phases, interactive access may be more appropriate as a 
contract compliance, data review, and internal analysis tool 
rather than for bulk transfers of complete LSAR master or other 
data files. 


50.4.2.1.4. Requirement for automated LSAR. Regardless of which 
deliverable option is selected, statement of work language (SOW) 
requiring the contractor to establish an automated LSAR 
capability should be included in the LSA Program SOW. (See 
Contract Implementation for Digital Data for sample SOW's.) 
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50.4.2.1.5. Use Of multiple L8AR data sets. Logistic support 
analysis is a dynamic, iterative process requiring real-time 
interaction between the design, engineering analysis and product 
support planning functions. By this means, logistics considera¬ 
tions are made an inherent part of the design process, not an 
after-the-fact consequence of design decisions that excluded 
support requirements. The requiring activity (the government) 
must identify what LSAR data is required, and the performing 
activity (the contractor) must decide how best to structure the 
CITIS in which that LSAR data is processed, stored, and made 
available to users while maintaining appropriate data protection 
and data integrity. These decisions must balance the requirement 
for continuous, real-time update of LSAR data that documents LSA 
tasks already performed and supports LSA tasks underway or yet to 
be performed, with the requirement to periodically baseline 
technical information about the product being designed. Such 
baselines are needed to support configuration management of the 
product and its technical data, and to meet contractual 
requirements. Cost is an important consideration in this 
decision — the additional costs of maintaining and reconciling 
multiple LSAR data sets, against the additional costs that result 
from losing configuration control of the product or of 
information about the product. The concept of working data, 
submitted data, and approved data is one solution to this 
problem, but it may not always be the optimum solution. Contract 
SOW requirements such as those suggested here must be established 
with due consideration of these program management and cost 
consideracions. 

50.4.2.2. Form option - decision #2. Each of the three 
deliverable options for the LSAR provides one or more viable form 
options. 


50.4.2.2.1. Form option - decision #2 (for LSAR reports). As 

shown at the top of figure 7, LSAR reports can be delivered 
either as hard copy reports or as a report image file. Hard copy 
reports include both computer-generated LSAR reports (Appendix B 
of MIL-STD-1388-2) and program-unique LSAR reports. Report image 
files, the digital equivalent of these reports, require no 
further data processing and can be loaded, viewed, and printed 
using standard system utilities. Both options are a fixed 
presentation of the r,SAR data and the applicable DID's must be 
selected for the desired reports. If the hard copy form is 
selected, the DID hard copy option should be noted. 

50.4.2.2.2. Form option - decision #2 (for LSAR data files). 

The single available form option, alphanumeric files, is 
discussed above. The use of an integrated data file is a future 


81 









MIL-HDBK-59 
APPENDIX B 


option presently under development that will be addressed in the 
next update to this handbook. 

50.4.2.2.3. Form option - decision #2 (for interactive access). 
As shown at the bottom of figure 7, interactive access to a 
contractor's LSA data base can take two forms: predefined queries 
or ad hoc queries. A predefined query is a established a fixed 
format, with a controlled set of options, to extract information 
from LSA source data. All of the LSAR reports including program- 
unique reports that are contractually required, as well as LSAR 
master files and data files, can be described as predefined in 
this context. With the format, content, and options already 
having been specified, the user selects the file or report 
(usually via a menu choice) to be displayed. On the other hand, 
ad hoc queries allow the aggregation and presentation of a 
contractor's LSAR source data to be defined by a user during an 
on-line session with the contractor's system. Ad hoc query 
capabilities are governed by the specific technologies and 
software of the contractor's system, and their availability will 
be controlled by the contract or other form of agreement. As 
CALS data standards for LSAR are developed, this limitation may 
be altered, as reflected by the dashed line for data standards at 
the bottom of figure 7. Until then, although the ad hoc query 
capability can be identified in the LSA SOW, it can only be 
defined by a contractor's proposal. Care should be exercised in 
evaluating contractor proposals to ensure that the proposed ad 
hoc query capability will satisfy government requirements. 

50.4.2.3. Specifications and standards - decision #3. There are 
no decision options on the standards for LSAR reports or LSAR 
master data files. These files are all alphanumeric tabular data 
files as specified in MIL-STD-1388-2. Since report image files 
can be generated by a sending system so easily, the technically 
feasible alternative of raster image data adds an additional 
level of data processing complexity, and is not a practical 
alternative. 

50.4.2.4. Digital delivery mode options - decision # 4 . As shown 
at the right of figure 7, there are two delivery mode options for 
LSAR report image files and for data files: physical media 
delivery or telecommunications transfer. Physical media consists 
of data delivery on magnetic tape, with the use of optical disk 
technology as a future alternative. Telecommunications involves 
the bulk electronic transfer of data files using network that is 
compatible with a specific telecommunications standard (DDN's 
TCP/IP, or OSI's GOSIP FIPS 146), or a public, or contractor- 
specific non-standard telecommunications network. If interactive 
access is not chosen for interim reviews, the most cost effective 
option for final delivery of LSAR reports and data files will 
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normally be magnetic tape. When an interactive access capability 
will be established, the cost and accessibility benefits of 
telecommunications versus physical media delivery modes must be 
evaluated. For physical media delivery, use existing or program- 
unique OID's and indicate the tape delivery option. Reference 
the tape media standards contained in Appendix D of this 
handbook. For telecommunications delivery of LSAR report image 
files or data files, the reports or data files to be 
electronically transferred should be included in the LSA program 
SOW. 


50.4.2.4.1. Interactive access. For the interactive access 
service, the only deliverable mode option is telecommunications. 
Options for selection of a telecommunications standard and 
delivery network are listed at the end of the telecommunications 
branch in figure 8. The choice depends upon the volume of data 
to be transferred, as well as the technologies in place at 
contractor and government facilities. 

50.4.2.4.2. Queries. If predefined queries are selected as the 
access form, the LSAR reports and files and the 

telecommunications standard should be included in the LSA program 
SOW. It ad hoc queries are chosen, the LSA program SOW must 
contain appropriate language without delineating specific report 
and data files. If both predefined and ad hoc queries are 
required, include this in the LSA program SOW and indicate the 
LSAR report and other files to be accessed. (See 50.4.4 for 
sample SOW paragraphs.) 

50.4.3. Decision guidelines. Options for delivery of LSAR data 
in digital form are not mutually exclusive. There will often be 
cases when several options will be combined for specific 
deliverables during a weapon system acquisition. The decision 
criteria presented in this handbook focus on the best options, 
but must be evaluated against program-specific requirements. The 
guidance below applies the decision criteria to the various LSAR 
options. 

50.4.3.1. Intended data use. The following guidelines apply: 

a. Select LSAR data files for consolidation of 
deliverables. 


b. Select LSAR data files if significant internal analysis 
of the data is anticipated. 

c. Select LSAR data files for input to automated 
government receiving systems. 
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d. Select interactive access with predefined queries to 
review LSAR data. 

e. Select interactive access with ad hoc queries to 
support unique analysis or delivery needs. 


50.4.3.2. Life cycle phases. The following guidelines apply: 

a. Select LSAR data files for later, high volume phases. 

b. Select interactive access to replace early phase LSAR 
deliverables. 

c. Select interactive access to support LSAR data reviews 
in all phases. 

d. Select LSAR hard copy reports for early phases if low 
volumes of data in the current or later phases do not 
justify the cost of additional automated processing. 

e. Select LSAR hard copy reports for nondevelopmental 
programs with limited service life data requirements. 

50.4.3.3. Delivery cost. The following guidelines apply: 

a. Select LSAR report image files if multiple report 
copies are required and the processing capabilities of 
government receiving system are limited. 

b. Select LSAR data files, in general, as the most cost 
effective option for all deliverables. 

c. Select interactive access to minimize on-site review 
requirements. 

d. Select magnetic tape for delivery of high volumes of 
digital data. 

50.4.3.4. Available technology. The following guidelines apply: 

a. Select LSAR hard copy reports or interactive access if 
no internal data processing system capabilities are 
available. 

b. Select LSAR report image files or interactive access if 
only limited internal data processing system 
capabilities are available. 
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c. Select LSAR data files for full scale development or 

production phases if internal data processing capabili¬ 
ties are available or planned for that time. 

50.4.4. Contract implementation for digital data. Automation 
and telecommunications technologies, while providing extended 
capabilities to industry and government, are altering the ways in 
which LSA and LSAR reporting and use are performed. The prior 
discussion of decision choices on the LSAR decision template 
indicated that there were six basic, yet non-exclusive, alterna¬ 
tives for delivery of digital data. These alternatives require 
that specific procedures be established for LSAR configuration 
management, interactive access controls, government review and 
feedback, and product delivery. The alternatives associated with 
telecommunications assume that an interactive access capability 
exists for LSAR report files. When existing functional standards 
are insufficient to describe the appropriate methods to contrac¬ 
tually invoke these alternatives, new SOW language must be 
provided. Each alternative has specific SOW phrases that should 
be included in the LSA program SOW. Sample SOW's are provided in 
the following text to implement the alternatives as summarized in 
table IV. 


TABLE IV. Summary of LSAR forms and standards. 


Deliverable and 

Form 

Preferred 

Delivery Mode 

Implement 

With 

1. LSAR Report 

Files 

Magnetic Tape 

New 

SOW #1 



2 . LSAR Report 

Files 

Telecommunications 

New 

#2 

SOW's 

#1 

& 

3. LSAR Master & 

Data Files 

Magnetic Tape 

New 

sow #1 



4. LSAR Master & 

Data Files 

Telecommunications 

New 

#2 

SOW'S 

#1 

& 

5. Interactive 

Predefined Query 

Telecommunications 

New 

#2 

SOW'S 

#1 

& 

6. Interactive Ad 

Hoc Query 

Telecommunications 

New 

# 2 , 

SOW'S 
& #3 

u 1 

T? / 



50.4.4.1. Sample SOW language. The following sample SOW's 
describe the contractor technology capabilities required by the 
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alternatives. These SOWs are cumulative based upon the 
combination of alternatives desired within the program. 

a. SOW #1 is suggested for automated LSAR capability. 

The contractor shall establish and maintain a validated LSAR 
automated data processing system capable of input, storage, 
and retrieval of LSAR data in accordance with MIL-STD-1388- 
2. The contractor may use an internally developed and 
validated LSAR automated data processing system, an 
independently developed and validated LSAR automated data 
processing system, or the government furnished Joint Service 
LSAR Automated Data Processing System. The validated LSAR 
automated data processing system shall comply with paragraph 
4.2.2 of MIL-STD-1388-2 and shall be used for the 
preparation of LSAR output reports as specified in the CDRL. 

b. SOW #2 is suggested for interactive access with prede¬ 
fined queries. 

The contractor shall establish and maintain automated sets 
of LSAR data for the management and control of the LSAR. As 
a minimum, the contractor shall maintain a set of LSAR 
working data for in-process review and a set of government 
approved LSAR data. The LSAR data contained in the working 
(in-process review) set shall be LSAR that has been 
subjected to internal contractor review procedures and 
frozen, pending government review and approval. The LSAR 
working data shall be updated in accordance with the 
schedule in the LSA plan regardless of the approval status 
of their content since the last update. Upon government 
approval, LSAR data contained in the working set shall be 
transferred to the government-approved LSAR data set. All 
government-directed changes resulting from the LSAR review 
process shall be incorporated prior to relocation of the 
data. The government-approved LSAR data shall be cumulative 
of all government-approved LSAR data. 

The contractor shall provide the government with interactive 
access to both the working and approved LSAR data sets. The 
contractor shall provide the means for controlling access 
capability. The interactive access capability shall include 
the ability to interrogate, retrieve, review, and print the 
following: 

1. Predefined standard LSAR summaries using established 
standard LSAR report selection procedures contained in 
the applicable Data Item Descriptions. 
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2. Any of the following government specified reports; 

(SPECIFY CONTENT, FORMAT, AND SEQUENCE OF EACH REPORT) 

The software will provide the capacity for terminal display 
of the specified queries or data files in 80 and/or 132 
character format and will include the capability to print 
the results of the queries on a local printer at designated 
locations. The user shall have the capability to specify 
queries by data set. User options shall include generation 
of queries from the working data, the approved data, or a 
combination of both. 

The contractor shall provide government with the interact ve 

access capability -. (SPECIFY PERIODS OF 

REQUIRED ACCESS, i.e.,. 0800-1600 EASTERN STANDARD TIME 
DAILY, 24 HOUR CONTINUOUS, ETC.) Government use of the 

access capability shall be limited to -. 

(SPECIFY ACCESS USAGE REQUIREMENTS, i.e., IN CPU 
MINUTES/MONTH, TOTAL CONNECT TIME, ETC.) Access shall be 
limited to the following locations: (SPECIFY LOCATIONS) 

The contractor shall establish telecommunications capability 
using one or more of the following methods and shall 
establish a means for ensuring completeness and accuracy of 
data transmissions. 

1. Point-to-point dedicated lines, 

2. A mutually acceptable commercial timesharing or packet 
switching network, 

3. Telecommunications equipment and networks compatible 
with OSI using FIPS 146, 

4. The Defense Data Network (DDN), or 

5. Another mutually acceptable method as defined in the 
contractor's proposal. 

In addition, the contractor shall provide: 

1. The hardware for each of the designated locations (if 
required). 

2. Maintenance for contractor furnished equipment and 
software (if required). 

3. Training for - (SPECIFY NUMBER) operators at each 

designated location. 
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4. - (SPECIFY NUMBER) set(s) of automated data 

processing system operator manuals and user 
documentation per location. 

c. SOW #3 suggested language for interactive access with 
ad hoc queries. 

In addition to the predefined LSAR output reports, the 
contractor shall establish the capability for on-line ad hoc 
query (report generation). Ad hoc reporting capabilities 
shall be defined by the contractor's LSAR automated data 
processing system software and presented in the LSA portion 
of the contractor proposal. As a minimum, the ad hoc report 
generation shall be capable of keying on and displaying the 
following LSAR data elements: LSA Control Number (LCN), 
Alternate LSA Control Number Code (ALC), Part Number, Item 
Name, Task Frequency, Federal Supply Code for Manufacturers 
(FSCM), Quantity Per Assembly, Unit of Measure Price, (ADD 
ADDITIONAL DATA ELEMENTS AS REQUIRED TO THIS LIST). 


50.5. ACQUISITION OF TRAINING PRODUCTS. 

50.5.1, Scope. This section provides guidance in determining 
training products to be delivered to the government in digital 
form, and describes appropriate acquisition alternatives. Many 
but not all training products are suitable candidates for digital 
development, delivery, and application. Many training products 
contain a combination of textual narrative and illustrative 
graphic images presented in a formal, structured, page-oriented 
format, which allows use of the same technologies and CITIS 
capabilities as are used for preparation and delivery of 
technical manuals. The guidance in this section assumes that the 
Instructional Systems Development (ISD) process described in MIL¬ 
T-29053 and the ISD deliverables identified in MIL-STD-1379D 
(DRAFT) or similar service-specific functional standards will be 
used to determine the appropriate form and format of training 
products to be delivered. 

50.5.1.1. Training products and media. Training products are 
used to train military personnel in the safe and effective 
operation and maintenance of weapon systems and equipment. They 
contain a composite of textual narrative and illustrative graphic 
images presented in a variety of media which are determined by 
program-specific training needs. Each of these products and 
media has particular attributes which make it an appropriate 
training solution to a particular set of training needs. 

Although training products can be developed in a variety of 
forms, they are all presented via a finite set of training media. 
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Each of these training media could be contracted for and 
delivered in a standardized digital format with varying degrees 
of ease and usefulness. The media used to present instiructional 
products can be grouped into the following media categories: 

50.5.1.1.1. Instructor-based training. Instructor-based training 
includes any form of training which utilizes an instructor, 
monitor, resource person, lab assistant, etc. Most of the 
training products which support instructor-based training could 
easily be contracted for and delivered as digital data. These 
products include instructor lesson plans, paper-based 
supplementary products, student workbooks, copies of visual 
training aids, performance evaluation tools, and job aids. 

50.5.1.1.2. Paper-based (page-oriented) training. The 

paper-based training category includes training that is conducted 
primarily by some form of paper-based material. Paper-based 
training products are page-oriented products in that information 
is organized and presented via a page. Paper-based training 
usually includes the use of self-paced or instructor lead 
workbooks, tutorials, or job aids. Also included in paper-based 
training products are reference guides such as technical manuals 
and system documentation. (These are addressed separately in 
this handbook.) A significant percentage of all training 
products currently developed are paper-based. Paper-based 
products and training products could easily be contracted for and 
delivered as digital data in much the same way as technical 
manuals. 


50.5.1.1.3. Computer-based training. Computer-based training 
refers to training which is delivered via a computer. 
Computer-based training includes tutorials, drill and practice, 
simulations, testing, and may also include embedded training. 
Computer-based training programs are already delivered in digital 
form to the government. However, they are currently delivered in 
a variety of formats and on a variety of magnetic media. 

50.5.1.1.4. Video-based and audio-based training. Video media 
includes video tape or film training packages, interactive video¬ 
tape training, and interactive video disc training. Audio-based 
training includes cassette tape programs, instructional records, 
training extension course tapes, and audio-workbooks. 

Audio-based training is often supplemented by paper-based 
training such as job aids or workbooks and visual-based training 
products such as slides. Current technology would not allow for 
video-based training programs to easily be delivered in a digital 
format. Delivery of audio-based training programs in digital 
form ir g'jite feasible. Whether or not it is cost effective and 
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useful to require audio-based training programs to be delivered 
in digital format is undetermined. 

50.5.1.2. Training products development. DoD has developed the 
ISO methodology as a standard approach for the development of all 
contractor produced training programs throughout the military. 

ISD is a highly structured methodology which calls for the 
development of standard interim products, such as reports and 
plans, and ongoing government review. This highly structured 
methodology lends itself to delivery of products in digital form 
for government review and approval before the contractor moves to 
the next step in the development process. For the purposes of 
simplicity, this appendix addresses deliverables set forth in 
MIL-STD-1379D (DRAFT). However, the guidance provided in this 
document also applies to other service-specific training 
development guidance documents. 

50.5.1.2.1. Interim products. The standard interim products that 
result from the ISD methodology typically include paper-based, 
page-oriented products such as training programs and training 
equipment plans; manpower, personnel, and training reports, 
personnel performance profile reports, media selection and 
syllabus reports; and course, module, and lesson objectives, etc. 
Additional products which may be developed in either paper-based 
or digital form include course, module, lesson flowcharts, tests, 
storyboards, and visual or video media shotsheets. The ISD 
methodology specifies that the government must review and approve 
each interim product before the contractor moves to the next step 
of the development process. 

50.5.1.3. Data sources for training products. The Logistic 
Support Analysis Record (LSAR) consolidates logistics-oriented 
technical information in conjunction with data for the various 
engineering disciplines and Integrated Logistic Support elements 
to reduce redundancy, facilitate timely usage, and enhance 
consistency between data elements and disciplines. The quality 
and productivity of training product development is enhanced when 
the LSAR is used as a principal data source for this process. 
Integration of the data bases that produce LSAR task analysis 
rand other) data, technical manuals, and training materials will 
provide even greater benefits. 

50.5.1.4. Coverage. This section only audresces the delivery in 
digital form of page-oriented training products. Requiring all 
training products to be delivered in a standard digital form 
would probably not be cost effective at this time. 

50.5.2. Decision option discussion. Figure 8 shows the decision 
template applied to page-oriented training product deliverables. 
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Decisions regarding whether training products should be delivered 
in digital form and the specifications for that form should be 
consistent with decisions made for other contract deliverables 
such as technical manuals. The following sections describe the 
decisions to be made in determining the form and appropriate 
specifications for training product deliverables. 


Decision *1 


Deliverable 



Composed 

Training 

Product 

Documents 



Processable 

RIes 


Interactive 
Access to 
Training 
Development 
Data 


Decision *2 

Form 
Hard Copy 


Decision «3 

ScSfi&Ji 

Standards 

MIL-STD-1379 


Print/Display RIe 


Text RIe 


r 

/■ 


MIL-R-28002/ 

MIL-STD-ie40 


SPDL 


MIL-M-28001/ 

MIL-STD-1840 



MIL-O-mOOO/ 

MIL-STD-1S40 


Graphics RIe 


< 


MIL-D-28003/ 

MIL-STO-1840 


Decision #4 

PgllvefY 

Mode 


Magnetic Tape 


Physical Media 




Optical Disk 


Telecommunications 




Legend: 


Current 

Future 


FIGURE 8. Decision template for training products. 

50.5.2.1. DelivereUsle options - decision #1. Training products 
can be delivered as either composed documents, or as processable 
data files. The use of interactive access is a future goal, 
largely because of the absence of integrated data bases of 
training data in sending systems. As these CITIS capabilities 
are established and merged with technical manual authoring 
systems, interactive access will become a practical alternative 
for review and approval of interim training products. 

50.5.2.1.1. Deliverable options - decision #1 (for composed 
training product documents) . The composed document deliverable 
option offers the least flexibility. It is a static, tomnatted 
presentation of the material which can only be archived, viewed, 
or printed after receipt. Documents can be delivered as either 
camera-ready hard copy, or as a digital print/display file. 
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50.5.2.1.2. Deliverable options - decision #1 (fsr processeible 
files). Processable training product data file deliverables 
offer more robust capabilities than document form deliverables. 
These files can be updated or transformed into many different 
document types. With the appropriate governmental receiving 
systems, processable files can support the development of summary 
guides, training aids, and eventual on-line distribution of 
selected poirtions of the data to trainees. Processable files are 
preferable because of their flexibility and maintainability; 
however the tools to permit acceptance and utilization of the 
information in this form are in various stages of development at 
this time. 

50.5.2.2. Form options - decision #2. 

50.5.2.2.1. Form options - decision #2 (for composed training 
product documents). The form for composed training product 
document delivery can be either a hard copy or a digital 
print/display file. The digital form of this deliverable 
consists of composed page images of material. It offers greater 
advantages in storage, distribution, viewing, and printing than 
hard copy. It also provides slightly more flexibility than hard 
copy with respect to future data uses, although its format will 
be fixed and unyielding. It is a two-dimensional image of each 
page, offering no further updating or processing features beyond 
replication. When changes are made, however, they can be more 
easily distributed than paper-based changes. 

50.5.2.2.2. Form options - decision #2 (for processable data 
files). At present, a processable file must comprise one set of 
files for textual or numeric data and separate files for 
graphics, i.e., illustrations and drawings. In the future, text 
and graphics files will be available as integrated data files 
with configuration management and positioning features. The 
technologies and standards to accomplish such integration and to 
allow joint processing or creation of the two data formats for 
concurrent presentation, however, are not yet sufficiently 
advanced. 


50.5.2.3. Specifications and standards - decision #3. 

50.5.2.3.1. Specifications and standards - decision #3 (for hard 
copy). Currently each deliverable form, with the exception of 
the processable files graphic file form, has one predetermined 
standard and specification. The hard copy form should be 
acquired in compliance with MIL-STD-1379D (DRAFT). 

50.5.2.3.2. Specifications and standards - decision #3 (for 
print/display files). The digital form of the composed training 
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product document, a print/display file, requires tailoring MIL- 
STD--1379D (DRAFT) by referencing the appropriate standards shown 
in 50.5.4. This data can also be delivered as raster page 
images, in accordance with MIL-R-28002. For most applications, 
the default Type I (xintiled) format is applicable. Storage of 
page images in a Page Description Language (PDL) provides an 
intermediate form which is slightly easier to maintain. PDL 
files can be acquired using MIL-M-28001. However, these are not 
standardized, for no Standard Page Description Language (SPDL) 
exists yet. 

50.5.2.3.3. Specifications and standards - decision #3 (for 
processable files) . Processable training product files comprise 
separate text and graphics files. There is only one available 
text file standard, MIL-M-28001 (SGML), but users must require 
creation and delivery of appropriate docviment type definition and 
output specification support files, as well as the SGML-tagged 
source file. There are several standards available for graphics 
files. As with technical manuals, a mixed mode deliverable, 
consisting of processable text in accordance with MIL-M-28001 and 
raster document image files in accordance with MIL-R-28002 is a 
viable option. Raster format is often an attractive, 
cost-effective alternative for converting existing paper-based 
drawings and illustrations into digital form. Because they offer 
more flexibility and utility, and may be created and used on a 
greater variety of computer systems, vector graphics are 
preferred for new weapon system acquisitions. Use of CGM is 
preferred, but IGES is allowed. MIL-D-28003 addresses CGM vector 
graphics data; based on program requirements for interim and 
final training product deliverables, the acquisition manager 
should choose between draft quality Level II and publication 
quality Level I CGM conforming metafiles. MIL-D-28000 addresses 
vector graphics in IGES format; the Class I technical 
illustration subset is most appropriate. 

50.5.2.4. Digital delivery mode - decision #4. As shown on the 
decision template, physical media are currently the only delivery 
mode option for the digital delivery of document image files or 
processable files. While a telecommunications bulk transfer of 
these files may be possible, it is not currently a feasible 
option because of the large volume of data contained in these 
files, particularly the raster page image and raster graphics 
files. Magnetic tape is currently the only physical media option 
available for the delivery of print/display files or processable 
files. Optical disk will become a future alternative physical 
media standard. For magnetic tape standards, reference the tape 
media standards contained in Appendix D of this handbook. 


93 








MZL-BDBX-59 
APPENDIX B 


50.5.3. Decision guidelines. Options for delivery of training 
products in digital form are not mutually exclusive. There will 
often be cases when several options will be combined for specific 
deliverables during a weapon system acquisition. The decision 
criteria presented in this Handbook can be used to help make the 
decisions on the decision template. The following is guidance 
for applying the criteria to training products. 

50.5.3.1. Intended data use. The following guidelines are 
provided: 


a. Select processable files if government update and 
maintenance is anticipated for the future. 

b. Select processable files if the future creation of 
specialized documents and aids is envisioned. 

c. Select raster image files if only an automated print- 
on-demand capability is desired or available. 

d. Select vector graphics files if update and maintenance 
of illustrations and drawings is desired. 

50.5.3.2. Life cycle phases. The following guidelines are 
provided: 

a. Raster image or print/display files should be acquired 
early in the life cycle of the program if most cost 
effective. 

b. Processable training product files should be the 
deliverable of choice when the government assumes the 
responsibility for training manual update and maintenance. 

c. Select static page-oriented documents if a program is 
in a late phase and large amounts of data already exist in 
paper form. 

50.5.3.3. Delivery cost. The following guideline is provided: 

Select magnetic tape for delivery because of the high 
volumes of digital data required by training products. 

50.5.3.4. Available technology. The following guidelines are 
provided: 

a. Options should be aligned to the automated publishing 
systems/computer resources in the Military Department 
receiving the deliverable. 
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b. Select hard copy if no internal data processing system 
capabilities are available or planned. 

c. Select raster print/display files if only minimal data 
processing capabilities are available internally. 

50.5.4. Contract Implementation for digital data. There are five 
basic, yet nonexclusive, alternatives for delivery of digital 
data. These are shown in table V. The existing functional 
standard is insufficient to contractually invoke these 
alternatives. Therefore, tailoring of MIL-STD-1379 is required. 


TABLE V. Summary of training products forms and standards. 


Deliverable and 

Form 

Preferred 
Delivery Mode 

Implement With 

1. Training Product/ 
Print Display 

Magnetic Tape 

MIL-R-28002 or Mil-M- 
28001 (PDL only), and 
MIL-STD-1840 

2. Processable 

Text File 

Magnetic Tape 

MIL-M-28001 

STD-1840 

and MIL- 

3. Processable Vec¬ 
tor Graphics 

File - IGES 

Magnetic Tape 

MIL-D-28000 

STD-1840 

and MIL- 

4. Processable Vec¬ 
tor Graphics 

File - CGM 

Magnetic Tape 

MIL-D-28003 

STD-1840 

and MIL- 


50.5.4.1. Training functional standard. Following its 
publication, reference the tailored MIL-STD-1379D in Block 16 of 
the CDRL (DD Form 1423) to specify delivery of digital data in 
accordance with its requirements and MIL-STD-1840. Pending 
publication of MIL-STD-1379D (draft), make its language part of 
the statement of work. The physical media standards for magnetic 
tape delivery mode shown in Appendix D should also be specified. 



50.6. ACQUISITION OF TECHNICAL SPECIFICATIONS 
AND REPORTS (RESERVED). 

(This section will provide a decision template and supporting 
rationale for the acquisition of technical specifications, 
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reports, plans, and other contractual deliverables involving 
integrated text and graphics, e.g., those prepared in a desk top 
publishing environment. The National Institute of Standards and 
Technology is doing the work and the results will appear in a 
future update of this handbook.) 


50.7. ACQUISITION OP INTERACTIVE MAINTENANCE AIDS (RESERVED). 

(This section will provide a decision template and supporting 
rationale for the acquisition of interactive maintenance aids in 
digital form.) 
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APPENDIX C 

FUNCTIONAL REQUIREMENTS FOR 
INTEGRATION OF CONTRACTOR PROCESSES 
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10. SCOPE 

10.1. Applicability. This appendix provides guidance to 
government activities on establishing contract requirements for 
functionally integrated contractor design and systems engineering 
processes on weapon system and major equipment development 
efforts. It is applicable to all Department of Defense (DoD) 
components which acquire weapon systems through the noirmal 
contracting process. 

10.2. Purpose. This appendix is intended to suggest the best 
methods for tailoring the wording of standard DoD Requests for 
Proposal (RFP's) and Contract Deliverable Requirement Lists 
(CDRL's) to allow and encourage the integration of design 
engineering, systems engineering, and support engineering efforts 
and the digital exchange of data among them. 


20. REFERENCED DOCUMENTS 

See list of references appearing in Appendix A. 


30. DEFINITIONS 

See list of terms and acronyms appearing in Appendix A. 
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40. GENERAL GUIDANCE 

40.1. Contracting for integration of functional processes. A 
major objective of CALS is the application of computer-aided 
methods and supporting technologies to incorporate logistic 
support functions as an integral element in the weapon system 
contractor's design process. To achieve this, the acquisition 
manager should apply the detailed requirements contained in 
section 50, tailored to fit the acquisition strategy selected for 
the program. These requirements specify the integration of 
design, manufacture, and support processes, as well as other 
elements of concurrent engineering, for the performance of DoD 
contracts. At a minimum, the general goals and objectives 
applicable to each identified functional area should be stated in 
industry informational briefings, commerce business daily 
listings, source solicitations, or instructions to RFP offerors. 
The full benefit to the program is realized only when the 
functional requirements are included in the RFP and the proposal 
evaluation/source selection process, and made contractually 
binding as described in section 50. 

40.2. Strategic approach. As CALS evolves, weapon system 
technical data will be logically integrated into tightly coupled, 
controlled, and secure CITIS and government technical.information 
system data bases, allowing access and authorized sharing of data 
at the data base level. Functional integration of contractor 
processes to ensure the security, currency, and accuracy of CITIS 
information will be articulated and contractually specified as 
CITIS requirements. CALS initiatives to improve technical data 
creation, management, and use provide an enabling environment 
that ’,vili accelerate the application of concurrent engineering, a 
systematic approach to creating a product design that considers 
all elements of the product life cycle from conception through 
disposal. In so doing, concurrent engineering simultaneously 
defines the product, its manufacturing processes, and all other 
required life cycle processes, such as logistic support. CALS 
functional requirements for concurrent engineering will provide 
the necessary focus for a comprehensive concurrent engineering 
strategy that addresses multiple approaches and the necessary 
enabling environment. Specific CALS thrusts, such as integration 
of R&M with CAD and CAE will directly contribute to application 
of concurrent engineering concepts. 

40.3. Application environment. The earlier in the acquisition 
cycle that this strategy is introduced, the greater the potential 
productivity and quality improvements. As decisions affecting a 
product's design are made, both acquisition and operational 
support costs become defined. The earlier in a system's design 
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definition that the user's requirements can be addressed by the 
product design and associated manufacturing processes, the 
greater the opportunity to produce a more robust, supportable 
design at lower life cycle cost and greater operational 
effectiveness. This requires a change to the way most companies 
function. For example, new product designs historically have 
been the property of the company's engineering department. When 
design and engineering analyses are completed, the design passes 
to manufacturing, where necessary engineering changes are 
identified, beginning a costly iterative process resulting in the 
as-designed vs. as-manufactured configurations of the product. A 
CALS and concurrent engineering strategy must begin at Milestone 
0 to produce the greatest returns in terms of development time, 
acquisition cost, life cycle support cost, and product 
reliability and maintainability. 

40.4. R&M Integration with CAD/CAB. The detailed requirements 
contained in section 50 are applicable to all engineering 
activities that define, establish, or influence reliability and 
maintainability (R&M) properties during all phases of item 
development, including concept exploration, demonstration and 
validation, full scale development, and production. The intent 
of section 50 is to influence the contractor to conduct 
engineering activities which have a bearing on the R&M properties 
of the ultimate fielded product, using computer aided design 
(CAD) and computer aided engineering (CAE) procedures that 
interact and actively share data with all other design 
engineering processes and procedures. Traceability of key design 
decisions having a major bearing on the R&M properties of the 
item to the engineering procedures, design criteria, and data 
bases that influenced the decisions is also a major goal. 

40.5. Integration of contractor LSA processes with R&M and 
design engineering. (Reserved). 

40.6. Configuration management of technical data. (Reserved) 

40.7. Concurrent engineering. (Reserved) 
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50. DETAILED GUIDANCE 

50.1. Organization of guidance sections. This section is 
organized into several major sub-sections, which can be used 
separately or together to contract for integration of contractor 
functional processes. 


50.2. PUNCTIONAL REQUIREMENTS FOR R&M INTEGRATION WITH CAD/CAE 

50.2.1. Purpose. This section provides guidance for the 
procuring activity in generating contractual requirements to 
achieve the integration of computer aided R&M engineering 
techniques with CAD and CAE in the development of weapon systems. 
It is applicable to all engineering activities that define, 
establish, or influence R&M properties during all stages of end 
item development, including concept exploration, demonstration 
and validation, full-scale development, and production. 

50.2.2. Impact of R&M. R&M has a decisive influence on weapon 
systems acquired by DoD. 

50.2.2.1. R&M Influence on effectiveness. Weapon system R&M 
characteristics influence the weapon system's operational effec¬ 
tiveness by driving its readiness for battle, sustainability 
during battle, and utilization of personnel and material during 
training and battle. It is recognized that good R&M 
characteristics are force effectiveness multipliers by offering 
the means to defeat a numerically superior force by engaging it 
repeatedly. Reliable weapons systems result in increased combat 
capability while employing fewer fielded spare parts and less 
manpower. Similarly, maintainable systems require fielding of 
fewer people and specialized skill levels, while achieving 
reduced maintenance times. Good R&M characteristics improve the 
mobility of forces because there are fewer people and less 
support equipment and spares to move. In short, the R&M features 
of each weapon system contribute significantly to the conflict 
capabilities of forces at sea and in the field. 

50.2.2.2. R&M influence on life cycle cost. The R&M 
characteristics of a weapon system are also key leverage points 
in determining the weapon system's total life cycle costs and 
operational effectiveness. An estimated 30 percent of life cycle 
costs can be traced directly to R&M characteristics of the weapon 
system's design. These costs occur not only as budgeted line 
items in the procurement and operations and maintenance 
appropriations for the particular weapon system, but also as 
indirect costs of the supporting logistics facilities and 
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activities, manpower, attrition replacements and replenishment 
spares. 


50.2.2.3. R&M in the design process. While conventional stand¬ 
alone post-design R&M engineering tasks, such as test, analyze, 
and fix (TT^AF), have been moderately successful in achieving 
improved R&M, these approaches are fundamentally limited by their 
inability to influence the design process itself. To a large 
extent, the R&M characteristics of a weapon system are attributes 
of its design, or more precisely, a direct function of the atten¬ 
tion given to them in the design process. They are analyzed into 
the design after it has been completed only with great difficulty 
and cost. Additionally, the R&M improvement effort must compete 
with integration and operational testing for test resources and 
schedule. 

50.2.2.4. CAE in development. The application of CAE resources 
to the R&M characteristics of weapon system development in an 
integrated design environment has the potential for effecting a 
quantum improvement in R&M. When applied to R&M design, CAE will 
provide the designer with closely-coupled, short-cycle analysis 
and feedback about the efficacy of the design approach so that 
corrective action and optimization can occur during the design 
process rather than later. In addition, concurrent design 
synthesis techniques offer’s superior inherent R&M design 
capability. In essence, CAE enables the designer to design the 
product right the first time with respect to R&M, the objective 
of Total Quality Management (TQM). 

50.2.3. General implementation guidance. The ultimate goal of 
integration of R&M into CAE is for all major design decisions 
affecting the R&M characteristics of the end item to be fully 
supported by automated procedures that are appropriate to the 
nature and level of the decision in a concurrent or 
near-concurrent fashion. 

50.2.3.1. Achieving the potential of CAE. Achieving the full 
potential of integrated CAE requires capabilities in five 
fundamental areas: 

a. Automated R&M analysis procedures tightly coupled to 
parts libraries and materials characteristics data 
bases. 

b. Automated R&M synthesis processes based on design rules 
incorporating lessons learned from prior design experi¬ 
ence and field use. 
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c. Fully characterized (tested and validated) component 
performance and R&M characteristics data bases. 

d. Configuration management procedures that link major 
design decisions affecting the R&M characteristics of 
the end item to: (1) the CAE software.and data bases 
used to develop decision criteria and otherwise support 
the decisions, and (2) the evolving configuration of 
the product, documented through configuration- 
controlled versions of the digital product description. 

e. a supporting stiructure of hardware, software, and 
computer networks adequate to support the procedures 
and processes of (a) through (d) above and to closely 
couple R&M-specific resources (including personnel) 
with the rest of the design team. 

50.2.3.2. Contrast of traditional and integrated approaches. 

Traditional R&M requirements take the form of independent tasks 
to be performed by the contractor as detailed in the contract 
Statement of Work (SOW), and in any R&M-related attachments and 
exhibits. The results of these tasks are to be delivered in 
accordance with the Contract Deliverable Requirements List (CDRL) 
in the format specified by a Data Item Description (DID). The 
integrated R&M functional requirement is different because it 
places an indirect requirement on the contractor's engineering 
resources, in the form of R&M-specific CAE techniques, 
procedures, and data bases. This indirect requirement 
necessitates a different contracting approach than does 
traditional R&M tasking, but is consistent with streamlining, and 
allows the contractor more freedom to determine how to satisfy 
the government's requirements. It replaces emphasis on specific 
SOW tasking with increased emphasis on the use of instructions to 
offerors and source selection criteria. This approach leads the 
contractor to tell the government how integrated R&M-specific CAE 
is to be applied to the program being bid, rather than telling 
the contractor how to apply it. 

50.2.3.3. Integrated procedure. In essence, using this 
approach, the government will ask the contractor to describe 
their existing and proposed R&M automation capabilities; award 
the contract based, in part, on the strength of the response; 
make any necessary adjustments during final negotiations; and 
incorporate the results in the ensuing contract. No additional 
CDRL items or DID's are required. CDRL items and DID's normally 
invoked to acquire R&M data can be tailored in ways that 
encourage the contractor to develop automated means for the 
generation and submission in digital form of these data. 
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Suggested wording to implement tailoring is presented in 

50.2.5.1. 

50.2.4. R7P and source selection guidance. The following 
guidance is provided on contracting for integrated R&M data. 

50.2.4.1. Approach. 

50.2.4.1.1. Instructions to offerors. Section L (Instructions 
to Offerors) of the Request for Proposal (RFP) should require the 
contractor to: 

a. Identify its capability and experience in the use of 
automated R&M functions. 

b. Explain to what extent R&M design tasks are integrated 
with its CAE system. 

c. Describe how specific CAE techniques, processes, and 
data bases will be used to satisfy R&M requirements. 

d. Describe how R&M data bases will be used to support 
logistic support analysis and record generation. 

50.2.4.1.2. Evaluation criteria. Section M (Evaluation 
Criteria) should be structured to emphasize these issues. 

50.2.4.1.3. Contractual Application. The offeror's proposed 
capability should be made part of the final contract. 

50.2.4.1.4. Summary of benefits. This process ensures that: 

a. R&M CAE functions are user-driven and not just 
responses to government requirements. 

b. R&M CAE is essential to winning contracts, and 
therefore will be given prooer emphasis. 

c. Specific R&M CAE capabilities will be used in the 
design and logistic support processes and will not be 
traded off or deleted because specific SOW requirements 
were not defined. 

50.2.4.2. Sample language. The following subparagraphs contain 
sample language that is recommended for incorporation in Sections 
L and M of an RFP. 
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50.2.4.2.1. Wording for Section L. The following wording is 
suggested for incorporation in Section L of RFP's: 

System Engineering: Computer Aided R&M Engineering Support 

The offeror shall submit a description of the way in which 
Computer Aided Engineering (CAE) techniques and related 
resources are to be used to ensure that design decisions 
affecting the ultimate R&M properties of the system (item) 
are adequately supported by automated trade-off analysis, 
engineering simulation, or concurrent design synthesis 
processes. This shall include a general description of the 
CAE environment within which design and development is 
intended to take place, and a specific description of the 
CAE capabilities dedicated to R&M support. It shall also 
include a discussion of the offeror's formal procedures to 
verify and maintain the accuracy and effectiveness of these 
R&M CAE capabilities by validating the quality of the 
engineering functional capability performed, data base 
maintenance, and development of lessons learned design rules 
from all sources of feedback. This documentation shall 
constitute a major element of Part III - Engineering 
Specialty Integration, of the System Engineering Management 
Plan (SEMP). The offeror's internal format is acceptable 
for this documentation. The System Engineering Master 
Schedule (SEMS) shall describe the timeliness of these 
inputs relative to the overall system engineering program 
and other design activities. 

The general description, including implementation status 
(current or proposed) of the CAE environment shall consist 
of the following: 

1) CAE hardware resources available to the program, 
including percentage availability of shared resources. 

2) CAE application programs available to the program, 
including source of commercial software, identification of 
proprietary software, and methods used to assure software 
quality. 

3) Integration approach, including communications 
networking, data base sharing and management, and 
configuration control. 

4) Policies, procedures, and organizational responsibility 
for control of CAE automation, specifically R&M automated 
tools. 
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5) Data standards and technical standards available for 
delivery of technical data to the government in digital 
form. 

The specific description of R&M resources based within the 
CAE environment shall consist of the following: 

1) An overview of the CAE resources, including hardware, 
software, and data bases to be applied to R&M. 

2) The degree to which R&M tasks and functions, including 
testability and manufacturability tasks, are automated. As 
a minimum, all tasks imposed in accordance with MIL-STD-470, 
MIL-STD-785, and MIL-STD-2165 shall be classified into the 
following categories: 

a. Not automated. 

b. Stand alone, no direct access to the CAE design data 
base. 

c. R&M algorithms reside within the CAE system, 
interfacing with the evolving resident item design when 
invoked. 

d. R&M algorithms reside with the CAE system, responding 
automatically to all initial inputs, derived factors, 
and design changes where appropriate to support a 
design decision. 

The offeror will receive credit in proposal evaluation for 
design-integrated R&M tasks and functions provided they are 
demonstrated to contribute to a coherent end-to-end R&M, 

CAE, or LSA engineering process. 

3) Descriptions of the offeror's formalized procedure and 
past history of deriving 'lessons learned' from test 
results, field feedback, and vendor data, and translating 
them into design rules incorporated into the CAE system. 

This is not intended to be a repetition of the offeror's 
plan for a Failure Reporting, Analysis, and Corrective 
Action System (FRACAS) for the specific program. It shall 
be a description of how the offeror uses information from 
vendors, testing, and the field to improve both products, 
and design and manufacturing processes on an institutional 
basis, and how that process is intended to be applied to the 
program. The description should contain the process for 
confirming and assigning a level of confidence to the design 
rules; the controls over R&M design rules that are exercised 
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by the R&M organization; and the process by which tradeoffs 
between R&M design rules, cost, and equipment performance 
are accomplished. 

4) A listing of the key design decision points influencing 
R&M in the proposed effort, the automated R&M functions that 
would be used to support them, and the relative time (with 
respect to major design reviews) of the decisions. 

5) Description of data bases to support R&M characteristics 
of the features, components and materials applicable to the 
program (e.g. preferred parts list), including supporting 
information on source of data (vendor, company tests, 
government data bases, etc.); confidence factors reflecting 
both quantity of their source, and whether or not they are 
based on estimates, simulation, broad categories of parts, 
tabular data, or actual measurements; applicability to the 
program; specificity and level of detail; and applicability 
to reliability, maintainability, or diagnostics. 

6) Description how product development configuration 
control procedures will be applied to R&M, including the 
capture of design decision criteria; discussion of the 
linkages between the design process and the R&M-specific CAE 
resources that were applied to it; discussion of 
traceability of design decisions to CAE resources, including 
software and data bases that supported them; and procedures 
in place to rapidly reassemble those resources to effect and 
record the impacts of an engineering change proposal with 
minimal impacts to the R&M characteristics of the system 
(item). State if this engineering history will be available 
to the government. 

7) Description of the integration of R&M-specific resources 
with the other product development resources, including 
personnel, CAE communication networks, application software, 
and data bases. 

8) The specific proposed wording for R&M CAD/CAE 
requirements to be imposed on all subcontractors of 
electronic subsystems, modules, assemblies, and custom 
components. The general criteria used to evaluate a 
subcontractor's responses to R&M CAE requirements relative 
to other criteria such as cost, schedule, and performance. 

9) Description of the offeror's internal procedures through 
which the automated R&M functions including supporting data 
bases are demonstrated to be correct, including conformance 
to industry standards if applicable. 
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10) Description of the capability to deliver Failure Modes, 
Effects, and Criticality Analysis (FMECA); predictions; 

LSAR; failure summary reports; and other R&M reports 
appearing in the attached contract CDRL as digital data in 
government-approved standard formats. 

50.2.4.2.1.1. Wording if risk reduction is required. If the 
Instructions to Offeror contain a requirement for a section 
describing a risk reduction effort, the following wording in 
addition to 50.2.4.2.1 is suggested: 

The offeror shall identify the intended use of Computer 
Aided Engineering (CAE) techniques to aid in reliability and 
maintainability risk reduction, outlining the risks to be 
addressed, how CAE is intended to help reduce them, and the 
benefit of CAE over other approaches, including level of 
risk reduced, accuracy, or timeliness of results. 

50.2.4.2.1.2. Wording if preliminary design is required. Where 
the Instructions to Offeror contain a requirement to provide 
preliminary design, system block diagram, functional partitioning 
of requirements, definition of configuration items, or 
preliminary system or item specifications, the following is 
intended to be added. The exact wording of the information 
requested from the' offeror should be substituted for the phrase 
preliminary design. 

It is critical that preliminary design data provided to the 
government by the offeror contain sufficient supplemental 
documentation so that the government can understand the 
design criteria used to support the preliminary design. 
Information documenting the CAE resources that supported 
major tradeoff decisions impacting R&M, including a 
description of the tradeoff decisions and a summary tracing 
the specific nature of the input to the decision from R&M, 
shall be provided. 

50.2.4.3. Sample language for Section M. The following wording 
is suggested for incorporation in Section M, Evaluation Criteria, 
of RFP's; 

The offeror's {technical/management/system engineering) plan 
will be evaluated for the extent of intended application of 
CAE. It is not adequate for evaluation purposes simply to 
cite the use of CAE on a blanket basis; i.e., CAE resources 
will be applied where applicable. The offeror must demon¬ 
strate their understanding of the use of CAE by including in 
a proposal a brief discussion of how CAE is to be applied to 
the R&M engineering process. The discussion should include 
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a specific summary of the CAE resources intended to be 
applied, the points in the development process where 
leverage from CAE is anticipated, any government required 
analysis that will be generated in whole or in part by CAE, 
and expected benefits to the program. The following 
specific criteria will be used: 

1) What is the capability described by the offeror for 
direct concurrent or near-concurrent synthesis of the R&M 
characteristics of the design based on design rules, 
embedded design knowledge, feature-based design, or lessons 
learned files? What major R&M design decisions are so 
supported? 

2) What processes does the offeror describe for conversion 
of lessons learned from the field or test processes to R&M 
design rules? Is there a formal process for creating, 
implementing, and validating new rules on the same CAE 
system/data base used to design the product? 

3) Are adequate design analysis tools available to provide 
the information necessary for trade studies and for support 
of other data requirements (e.g., logistics)? Do these 
tools interact with relevant CAE design data base parameters 
as they evolve? 

4) Are the R&M-specific CAE feature, component, and 
materials characteristics data bases (including failure 
properties, mechanical properties, and component models to 
support detailed engineering simulation of the product) 
adequate to support the design effort required? To what 
extent are they validated? 

5) If the government plans to take over responsibility for 
sustaining engineering, to what extent will the offeror 
provide design decision traceability, including supporting 
data packages or data files? Are the interfaces between the 
contractor and the government, and between the contractor 
and any suppliers, adequate to support transportation of 
product data and models? 

6) Does the offeror intend to employ sufficient CAE 
resources, including hardware, software, integration, and 
networking facilities, to adequately reduce risk and 
accomplish the proposed R&M program in a timely fashion? 

50.2.5. Contract requirements. Contractor responses to Section 

L of the RFP should be used in final negotiations with the 

winning contractor. The object is to incorporate as contract 
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requirements all proposed items that the government and 
contractor believe will provide significant benefits to the 
design in terms of improved R&M performance. As contract 
requirements, the chance of R&M CAE functions being eliminated 
due to pressures from other program elements (e.g., costs, 
schedule) will be minimized. 

50.2.5.1. CDRL items. No additional Contract Data Requirements 
List (CDRL) items are required as a result of R&M CAE implemen¬ 
tation. While R&M CAE may reduce CDRL costs for some items, the 
specific CDRL requirements for each program should be based on 
specific government needs for design data. 

50.2.5.2. Tailoring. In general, the CDRL lists the data to be 
delivered under the contract, frequency of submittal, generation 
procedures, and required formats. One method of motivating 
contractors to undertake R&M tool development and integration is 
to tailor the CDRL and the associated DID's. Selected tailoring 
can accomplish this goal by providing incentives for automated 
data item generation. A recommended tailoring approach for each 
of these elements is discussed below, followed by models of 
contract wording where appropriate. 

50.2.5.2.1. R&M task selection. The availability of computer 
processable data must be considered when attempting to encourage 
the automation of any R&M task. The selection of the R&M tasks 
to be accomplished and the associated data items delivered are 
development phase dependent. This information can also be found 
in various military standards that describe the requirements for 
R&M programs. When an R&M task is required, the level of data 
expected to be available must be considered. For example, during 
the concept exploration phase, the Failure Modes, Effects, and 
Criticality Analysis (FMECA) can be performed to the functional 
level. The detailed level of digital data available during the 
full scale development phase, however, permits the accomplishment 
of the FMECA down to the device level. Where the offeror 
proposes to use CAE to support an R&M analysis task, the 
government program office can expect higher quality and 
timeliness in delivery of detailed data in a more useable form. 

50.2.5.2.2. CDRL/DID cross references: tailoring for digital 
format. The CDRL will include a reference to the procedures 
required to perform the data item generation and to the desired 
format by referencing the Data Item Description (DID) to be used 
in Block 4 of DD Form 1423. During the phase-in period, the 
contractor can be encouraged to use automated data item 
generation capabilities by permitting data to be delivered in 
formats and standards that are not in conformance with CALS 
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directives. The following CDRL wording may be used in Block 4 of 
DD Form 1423: 

Block 4: If automated data item generation capability is 

used, contractor's format is acceptable. 

50.2.5.2.3. Tailoring: frequency of submissions. In an effort 
to reduce the number of submissions required, one CALS objective 
is to establish government access to contractually approved 
portions of the contractor's CITIS data base. The program office 
should explore this option where applicable to reduce data 
delivery. 


50.2.5.2.4. Tailoring DID language. The DID references the 
appropriate military standards and guidance to be used for data 
item generation, and includes formatting instructions. 
Generally, DID's are tailored to account for unique program 
aspects. Tailoring of the procedures and methods required for 
data item generation and the format of the deliverable can also 
encourage automation of the data item preparation task. The 
following wording is suggested: 


It is recommended that the contractor employ automated 
capabilities in the generation of the data items required. 
Modification of the submission format consistent with the 
level of automation proposed is acceptable. Submission of 
data in digital format is encouraged. 


50.3. FUNCTIONAL REQUIREMENTS FOR INTEGRATION OF CONTRACTOR LSA 
PROCESSES WITH R&N AND DESIGN ENGINEERING. 

50.3.1. Purpose. This section provides guidance for the 
procuring activity in generating contract requirements for 
integration of LSA and R&M engineering processes. These 
processes are often performed by separate contractor 
organizations, supported by separate automated systems. 
Integration can reduce duplication of effort, improve the 
consistency and quality of data, and improve the quality of the 
system or item under development. The following statement of 
work (SOW) language is appropriate when the contractor has, or is 
expected to have, automated LSAR and R&M data systems. 

50.3.2. Suggested contract wording. The following wording is 
suggested for incorporation in the SOW: 

The contractor shall identify in the LSA plan the 
procedures, either automated or manual, that will be used to 
ensure LSAR documentation requirements for reliability and 
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maintainability (R&M) information are satisfied through use 
of appropriate (R&M) data sources. The procedures shall 
describe how R&M source data are to be used in developing 
the LSAR, and shall address initial R&M inputs as well as 
change control for data additions, deletions and 
modifications. The procedures shall also identify the 
algorithms or transformations that must be applied to source 
data elements to conform to LSAR documentation requirements. 
The procedural description shall be of sufficient detail to 
clearly demonstrate traceability between the LSAR and 
individual R&M data sources, and the preservation of 
appropriate data flows while maintaining established LSAR 
data element relationships and interdependencies. 


50.4. FtTNCTIOMAL REQUIREMENTS FOR CONFIGURATION MANAGEMENT OF 

TECHNICAL DATA. (RESERVED) 

(This section will provide suggested SOW language for 
configuration management capabilities in government-owned, 
contractor-maintained data bases that support integrated 
functional processes. The CALS Industry Working Group on 
Configuration Management and Indexing is doing the work and the 
results will appear in a future update to this military 
handbook.) 


50.5. FUNCTIONAL REQUIREMENTS FOR CONCURRENT ENGINEERING. 

(RESERVED) 

(This section will provide suggested SOW language for application 
of a concurrent engineering strategy as part of the design and 
development process for weapon systems and major equipment items. 
The CALS Industry Working Group on Concurrent Engineering is 
doing the work and the results will appear in a future update to 
this military handbook.) 
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10. SCOPE 

10.1. Applicjibility. This appendix provides guidance to 
government activities on the use of physical media and 
telecommunication networks for delivery of technical data in 
digital form, or digital access to technical information data 
bases. It is applicable to all Department of Defense (DoD) 
components which acquire weapon systems and related major 
equipment items, and their associated technical data. 

10.2. Purpose. This appendix is intended to suggest the best 
methods for defining statement of work (SOW) requirements, and 
tailoring the wording of DoD Requests for Proposal (RFP's) and 
Contract Data Requirement Lists (CDRL's) to allow and encourage 
the integrated preparation and submission of, or access to, 
technical data in digital form. 


20. REFERENCED DOCUMENTS 

See list of references appearing in Appendix A. 


30. DEFINITIONS 

See the list of terms and acronyms appearing in Appendix A. 


40. GENERAL GUID^ /'E 

40.1. Access and delivery of digital data. A major thrust of 
the Computer-aided Acquisition and Logistic Support (CALS) 
program is access to, and delivery of, weapon system technical 
data in digital form. This appendix provides guidance for 
contracting for the delivery alternatives discussed in Section 5 
and Appendix B of this handbook. 
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50. DETAILED GUIDANCE 

50.1. Organization of guidance sections. This appendix is 
organized into two major sections that address physical media and 
telecommunications alternatives for data delivery or access. 

These sections can be used separately or together to contract for 
technical data in digital form. 

50.1.1. Options. The Decision Template for Acquisition of 
Digital Data reflects two options available for delivery of 
digital documents and processable data files, together with a 
single option for interactive access to CITIS data bases. The 
technology for both options has advantages for the user, and 
limitations on the ability to benefit from those advantages. 

50.1.1.1. Physical media. Older types of physical media (i.e., 
magnetic tape) provide a mature, stable technology in which the 
user can place great confidence. Unfortunately, this media form 
is also slow, bulky, and cumbersome. Newer types of physical 
media (i.e., WORM optical disk and CD-ROM) hold great promise 
because of their much greater storage capability, but standard 
data formats are only now beginning to emerge, and 
interoperability remains a problem. Unlike magnetic tape, where 
system hardware investment is largely a sunk cost, use of WORM 
optical disk or CD-ROM may involve substantial investment costs. 

50.1.1.2. Telecommunications. Secure, on-line transmission of 
the full volime of technical data for major weapon systems is 
technically feasible, but beyond the economical capability of 
current telecommunication networks in DoD and industry. In the 
near term, telecommunications will be limited to electronic mail 
exchange of high priority technical data, and interactive access 
where traffic volume is limited to queries, selective review and 
approval of data, or other clearly defined uses. In the longer 
term, cost effective and secure telecommunications capability 
will be essential for successful implementation of the IWSDB. 
Substantial amounts of government and industry research are 
underway to provide this capability. CALS is helping to define 
user requirements in this area. Development and implementation 
of DoD telecommunications capability is the responsibility of the 
Defense Communications Agency, under the policy guidance of the 
Assistant Secretary of Defense for Command, Control, 
Communications, and Intelligence. The National Institute of 
Standards and Technology can provide additional information on 
existing and planned commercial and government capabilities. 
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50.2. Physical media. 

50.2.1. Physical media options. Physical media options include 
magnetic tape, magnetic disk, and several forms of optical media. 
Magnetic tape is the preferred physical medium for delivery of 
technical data in digital form because it is a mature, stable 
technology that is able to handle the large volumes of data 
typically involved in a major weapon system acquisition. 

Standards are well defined and usually well implemented, and 
little investment cost will be involved because almost all CITIS 
source systems and government destination systems provide 
magnetic tape read/write hardware. Magnetic disk is also widely 
implemented on personal computers and work stations, and may be 
the physical medium of choice for small business contractors. 
Several primary de facto magnetic disk formats are available, but 
no official standard has been accepted. Compatibility problems 
exist, but can be overcome with only moderate effort. Optical 
media is used here as a generic term to include CD-ROM (compact 
disk, read only memory), CDI and DVI (compact disk interactive 
and digital video interactive), WORM (write once and read many 
times), and erasable optical disk. 

50.2.1.1. Magnetic tape. Magnetic tape includes three principal 
tape densities, only two of which are acceptable for delivery of 
technical data in digital form. The oldest is 800 characters per 
inch. Though still in use in many government and industry 
automated data processing systems, CALS government and industry 
users have decided that this is essentially obsolete technology, 
and is no longer an acceptable tape density for the large volumes 
of technical data that CALS data deliverables will typically 
encompass (see MIL-STD-1840). Instead, acceptable tape densities 
are 1600 and 6250 characters per inch, written on 9-track tapes 
in accordance with the Federal Information Processing Standards 
listed in MIL-STD-1840, paragraph 5.2.1. MIL-STD-1840 also 
includes specific instructions on single and multi-volume tapes, 
and data file organization. To acquire digital deliverables on 
magnetic tape. Block 16 of the CDRL (DD Form 1423) should be 
modified to incorporate the appropriate language from MIL-STD- 
1840. 


50.2.1.2. Magnetic disk. The revolution that has changed 1970's 
mainframe computing to 1980's distributed, desktop computing has 
made magnetic disk a viable alternative for interchange of 
digital technical data. Although most large companies have 
implemented local area networks (LAN's) to interconnect 
individual users, magnetic disk (floppy disk and removable hard 
disk) remains a major medium for moving digital data among 
personal computers and work stations. For small business, where 
LAN's are not yet as widely implemented, magnetic disk remains 
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the dominant exchange medium. Magnetic disk may have only a 
limited role to play in delivery of technical data in digital 
form to the government, but it may have a major role in exchange 
of digital data among prime contractors and subcontractors. Most 
government destination systems are not prepared to receive 
digital data on magnetic disk, although jury rig solutions are 
not difficult. Acquisition managers should examine closely the 
role that magnetic disk could play as a digital delivery medium 
in specific program applications. 

50.2.1.3. Optical madia. For simplicity, the term optical media 
is used in this handbook to encompass several categories of 
physical media that have distinctly different physical and 
technical characteristics. Usually these categories are not 
lumped together, and computer specialists will draw major 
distinctions between each form. However, all these forms share 
one important characteristic: they are not yet ready for 
widespread use as a medium for digital delivery of technical 
data. Four categories are addressed in the following sections. 

50.2.1.3.1. CD-ROM. DoD is conducting demonstrations and 
prototypes of CD-ROM technology for distribution of technical 
publications and other forms of technical data. CD-ROM disks are 
produced in a mastering studio, the investment cost of which 
remains significant. CD-ROM players are approaching the status 
of "standard option" on personal computers. However, data on a 
CD-ROM disk cannot be changed. The disk itself cannot be 
updated, only replaced. 

50.2.1.3.2. GDI and DVI. This is a very new technology, which 
combines the capabilities of CD-ROM with video. It is still 
expensive because it has not yet left the research and 
development phase, and it has limitations on the amount of 
information it can communicate. CDI and DVI are competing 
approaches for providing a standard implementation of this 
technology. As the technology matures, and its cost declines, 

CDI will probably find its first application in digital training 
products. 


50.2.1.3.3. WORM. This form of optical disk will be the first 
to be routinely used for delivery of digital data. It is the 
basis for DoD's automated engineering data repositories, and is 
being widely implemented by large contractors. (It is not as 
widely implemented as CD-ROM among smaller contractors and 
individual users.) Unlike CD-ROM, WORM optical disks can be 
updated at the user's work station. However, updating consists 
of writing a new file and file directory onto the disk. The old 
data is not replaced, so eventually an optical disk becomes full. 
To offset this disadvantage, the inability to erase or replace 







MIL-HDBK~59 
APPENDIX D 


data means that every configuration change is permanently 
documented. Current technology includes several WORM disk sizes. 
Twelve inch disks and the newer fourteen inch disks are primarily 
used for data storage by central repositories, and will be the 
medium for data delivery in only a few cases where (literally) 
huge volumes of data are being delivered. Five-and-a-quarter (5 
1/4) inch disks will be used by DoD to exchange data between 
primary and secondary repositories, and will be a storage medium 
for digital technical data at desktop work stations. Even 
smaller disk sizes are now appearing. These are the disk sizes 
that will probably become the primary physical medium for data 
delivery in the near future. However, the investment cost for 
optical disk read/write hardware remains a barrier to 
implementation. Also, standards for physical formatting and 
logical formatting of optical disks are still being defined. 

50.2.1.3.4. Erasable optical disk. This is another new 
technology, the routine application of which remains several 
years away. This category of optical disk can be both read and 
written at the individual work station, just as a magnetic disk 
is today. DoD and industry will implement this technology in the 
future, and most probably will eventually make it the principal 
physical medium for exchange of digital data. However, the 
technology itself is still emerging; standardization remains 
several years away. 

50.3. Telecommunications. 

50.3.1. Telecommunication options. In the current environment, 
the user of telecommunications for either data delivery or access 
has three options. The government and the contractor must work 
together to select the option that best fits user requirements 
and available capabilities. 

50.3.1.1. Contractor-specific networks. The first option is use 
of an existing, oftentimes non-standard network already 
established by the contractor. The government, in effect, is 
hanging terminals onto the contractor's system, and becoming 
another node of the CITIS. In this case, the acquisition manager 
has the advantage of using an existing investment and a proven 
data architecture, and the disadvantage of being a captive 
audience. Nonetheless, this is a highly practical solution to an 
immediate requirement. Depending on the type of terminal and 
software used, and the procedures established for system and data 
protection and integrity (see Appendix E), processable data files 
can be downloaded onto physical media (e.g., a magnetic disk). 

The data are then available for additional processing and 
transformation under the control of the acquisition manager. 
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50.3.1.2. TCP/IP-based ODN. The second option is providing the 
contractor with an interface to the Defense Data Network (DDN). 
Because the DDN is a DoD network, sized to support defense 
requirements within available funding, the acquisition manager 
must provide sponsorship for defense contractor nodes, and must 
satisfy Defense Communications Agency requirements to justify and 
schedule connection to the network. The DDN is currently based 
on the Transmission Control Protocol and Internet Protocol 
(TCP/IP) standards which are widely supported in government and 
industry with many commercial, off-the-shelf products. However, 
DoD has coiamitted to accompany industry in the transition to Open 
System Interconnection (OSI) compatible products, implemented 
through new standards such as the Government OSI Profile (GOSIP). 

50.3.1.3. OSI compatibility. The third option for 
telecommunications is OSI compatibility, the telecommunications 
technology that industry as well as government is moving rapidly 
to implement. Unfortunately, OSI products won't be in widespread 
government use for several years, and R&D is still needed to 
address major issues such as data protection and integrity. 
Nonetheless, standards have already been established, and DoD has 
established a timetable for conversion from TCP/IP-based to OSI- 
based technology. As OSI-compatible DDN networks are 
established, the acquisition manager must meet Defense 
Communications Agency requirements to establish connectivity. 
However, implementation will be simplified because future 
industry telecommunications networks will also be OSI-compatible. 

50.3.2. DDN compatibility. The DDN was developed in the 1960's 
to satisfy DoD telecommunication requirements. DoD helped 
pioneer this technology. Like most pioneers, DoD implemented 
systems from which later computer and telecommunication experts 
learned the improvements that would be needed to make widespread, 
standardized telecommunications technology more effective and 
more efficient. DoD will transition to the new OSI-compatible 
technology, but the legacy investment in TCP/IP-based technology 
means that this will not happen overnight. 

Each DoD component has developed specific implementing technical 
language to accommodate its network-specific needs within a 
common DDN architecture. The following sections summarize (and 
generalize) that component-specific language. This information 
is not intended to substitute for component-specific technical 
requirements, but rather is intended to inform the acquisition 
manager of the general framework of capabilities that should be 
required. These generic requirements are for the current TCP/IP- 
based DDN only, and do not include requirements for migration to 
the OSI standards. They include DDN protocols up to and 
including the file transfer protocol, simple mail transfer 
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protocol, internet control message protocol, and TELNET. They do 
not address environmental considerations, performance 
requirements, training manuals, maintenance/warranty provisions, 
special security, installation, or network control. 

50.3.2.1. Interface with the DDM. The contractor should provide 
the appropriate number of DDN interfaces for each host, node, or 
LAN. Long-haul or packet-oriented LAN communications capability 
will be provided by the DDN. The contractor should supply all 
required hardware, software, and accessory equipment necessary to 
achieve DDN operability for the proposed system. Each DDN 
interface node or host within the proposed configuration will be 
connected by the contractor to a DDN access circuit, which will 
be extended by the government to the site wherein the proposed 
system is installed. The contractor should provide the necessary 
cabling between the DDN access circuit terminus and the 
designated interface node or host. 

50.3.2.1.1. Data protection and integrity. All hosts interfaced 
to DDN should be capable of being certified at an appropriate 
security level by an agreed upon date. Hardware, software, and 
procedures should be adequate to prevent misuse or abuse of both 
the system (computers and telecommunications) and data resident 
in the system (Appendix E). 

50.3.2.1.2. Topology. If LAN topology is proposed, a gateway to 
DDN should serve as the interface device. Neither a LAN nor a 
gateway is required; only the DDN interface itself is a require¬ 
ment. Another topology may be proposed. If a LAN is proposed 
that is packet-oriented, each designated DDN host on a particular 
LAN should have MIL-STD-1777/1778 installed for intra-LAN 
information transfer, along with internet control message 
protocol, MIL-STD-1780/1781/1782. If an Ethernet LAN is 
proposed. Request For Change 826 should provide address 
resolution between IP and LAN media access control. The Ethernet 
LAN will be IEEE 802.3 compliant. 

50.3.2.1.3. Gateways. If a DDN LAN gateway is proposed, the 
contractor should provide the hardware and software necessary to 
serve as a DDN gateway between the proposed system and the DDN, 
and should interface the gateway to both the proposed system and 
the DDN packet switching node. The gateway should be implemented 
in contractor-provided equipment independent of the proposed 
system. The contractor should supply all appropriate gateway 
protocols to allow full communication between hosts and terminals 
on the proposed system and those on the DDN. The proposed system 
interfaces should provide transparent internetwork addressing and 
complete functional interconnectivity to the user. The gateway 
should be connected to the LAN, should support a minimum of 256 
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logical connections simultaneously, and should implement the 
channel access protocol for interfacing the gateway with the LAN. 
Hardware and software used to connect the gateway to the LAN 
should be provided. The connection to the LAN should support the 
minimum data transfer rate specified for the full-duplex gateway 
to DDN packet switching node interface. 

50.3.2.1.4. Interfaces. The data link and network interface 
should comply with the DDN X.25 host interface specification. 

The physical interface should also comply with EIA RS-449, and 
should be capable of transmitting and receiving binary data at 
all of the following discrete data transmission rates: 4800, 

9600, 19200, 50000, and 56000 bits per second. The electrical 
interface should comply with EIA RS-422-A and MIL-STD-188-114. 

The DDN exterior gateway protocol and all internet protocol (MIL- 
STD-1777 and supporting Defense Communications Agency 
interpretations) should be implemented in the gateway. The IP 
software should be able to automatically operate with receiving 
IP's that have not implemented identical IP options. Internet 
control messages should conform to the requirements of the 
internet control message protocol, and should be capable of 
receiving all message protocol message types. 

50.3.2.2. DDN protocols. The contractor should provide the 
necessary protocol support to achieve the specified level of 
service interface with DDN. The network, TCP, and IP (as 
appropriate) protocols must be accessible by the user from higher 
layer services and user-developed code via service access 
protocols within each respective protocol in order to permit 
localized adaptations to the interface. Specific software 
procedures required to use the services of applicable protocols 
should be documented and made available to the government. 

50.3.2.2.1. Transport service. For transport service, all TCP 
options specified in MIL-STD-1778 should be implemented, and all 
TCP systems parameters should be settable. The TCP software 
should be able to automatically operate with a receiving TCP that 
has not implemented identical TCP options. 

50.3.2.2.2. Application level protocols. Terminal-to-host 
service should conform to MIL-STD-1782, including all DoD- 
approved TELNET options. All functions available to locally 
connected users should also be available to remote users at all 
locations following successful implementation of both system and 
application sign-on procedures. Some application functions may 
not have specific sign-on procedures. File transfer service 
should conform to MIL-STD-1780. At a minimum, ASCII and image 
data representations should be accepted. Electronic mail service 
should conform to MIL-STD-1781. In addition, an end-user mail 
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handler that utilizes the facilities of simple mail transfer 
protocol and the local file system should be provided, and should 
establish and maintain user mailboxes as required, and support 
appropriate mail host administrator functions. The end-user mail 
handler should automatically send or receive mail via KIL-STD- 
1781 ports, with logical-to-network address translation. 


50.3.2.3. Host-to-host front-end protocol interface (network and 
data link and physical layers) . The physical interface should 
conform to EIA RS-449 and MIL-STD-118-114. The interface should 
be capable of transmitting and receiving binary data at one or 
more of the following discrete data transmission rates: 4800, 
9600, 19200, 50000, 56000, and 64000 bits per second. Data link, 
network interfaces, and service access for host-to-host front-end 
protocol communication should conform to the DDN host front-end 
protocol and service access protocols. The host front-end 
protocol link should conform to FED-STD-1041 (FIPS PUB lOO-l). 

Two way simultaneous operation should be supported. 


50.3.2.4. Stibscriber interface. These requirements apply only 
to systems requiring Defense Communications Agency-approved 
interfaces. Government users who need unique, custom-designed 
DDN connections should define the specific characteristics of 
that interface following the DDN layered hierarchy description. 


Examples of Standard DDN Protocols 


Physical 
Data Link 
Network 
Transport 
Session 

Presentation (and) 
Application 


RS-449, RS-232-C 
High-level data link control 
DDN X.25 (Standard) 

TCP/IP 

Local 

TELNET 

File Transfer Protocol, Simple 
Mail Transfer Protocol, Native 
Mode, Special User Applications 
as Required 


50.3.2.5. System-specific modification. The protocols listed 
above are examples of a DDN standard configuration. Where 
special needs exist, they should complement, not replace, the 
basic DDN protocol structure. The system definition may require 
modification based on the unique needs of each acquisition, but 
the overall layered protocols used by DDN will be intact 
Special, non-approved vendor protocols cannot substitute for 
listed DDN protocols. They roust exist, if needed, outside the 
DDN domain. 
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50.3.3. OSI compatibility. The preferred future standard for 
telecommunications media access and delivery are protocols that 
provide Open System Interconnection (OSI) compatibility. OSI 
protocols have been developed by international standards 
organizations, primarily the International Organization for 
Standardization (ISO) and the Consultative Committee on 
International Telephone and Telegraph (CCITT). To provide OSI 
compatible networking capability for government users, a 
government OSI profile (GOSIP) has been published as a federal 
information processing standard. GOSIP defines the initial suite 
of protocols through which DoD and other government agencies will 
transition from current heterogeneous telecommunication systems 
to an OSI architecture. 

50.3.3.1. Origin of GOSIP. GOSIP defines a common set of OSI 
data communication protocols which enable systems de\eloped by 
different vendors to interoperate and enable the users of 
different applications on these systems to exchange information 
without use of physical media. GOSIP is based on agreements 
reached by vendors and users of computer networks participating 
in the National Institute of Standards and Technology's Workshop 
for Implementors of Open System Interconnection. To provide 
completeness, GOSIP is augmented with material from international 
standards and documents progressing toward international standard 
status. 


50.3.3.2. General application. The GOSIP (FIPS 146) is 
effective as of February 25, 1989. For a period of eighteen 
months thereafter, until application of GOSIP becomes compulsory 
and binding, agencies are permitted to acquire alternative 
protocols that provide equivalent functionality. However, 
agencies are encouraged to use the standard for solicitation and 
contracts for new network products and services to be acquired 
after the effective date. For the indefinite future, agencies 
will be permitted to buy network products in addition to those 
specified by GOSIP and its successor documents. This includes 
other non-proprietary protocols, proprietary protocols, and OSI 
features and options not yet included in GOSIP. 

50.3.3.3. DoD application. Waivers to FIPS may be granted under 
certain exceptional circumstances. However, DoD policy on the 
use of GOSIP was established even before the GOSIP FIPS was 
published. GOSIP was adopted in 1987 as an experimental co¬ 
standard to the TCP/IP protocols that provide similar services 
within the current structure of the Defense Data Network. GOSIP 
could be specified in addition to, in lieu of, or as an optional 
alternative to the DDN protocol standards. Now that the ''OSIP 
FIPS has been formally published, it is a full DoD co-standard, 
and after the established transition period will become the sole 
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mandatory interoperable protocol suite. However, a capability 
for interoperation with the DDN protocols has been provided to 
ensure that existing systems can continue to function fully and 
effectively. 

50.3.3.4. Industry compatibility. GOSIP is consistent with, and 
complementary to, industry's manufacturing automation protocol 
(MAP) and technical and office protocol (TOP). MAP/TOP addresses 
a broader range of functionality, and defines more advanced 
technology as a way to establish guidelines for future commercial 
product development. 

50.3.3.5. GOSIP implementation and extension. GOSIP addresses 
the need of the federal government to move immediately to multi¬ 
vendor interconnectivity without sacrificing essential 
functionality already implemented in critical networking systems. 
All capabilities specified in GOSIP exist as standard products or 
are close enough to market that they can be proposed by vendors. 
OSI protocols providing additional functionality will be added to 
GOSIP as implementation specifications for those protocols are 
developed by the OSI Implementors Workshop. For each incremental 
extension to GOSIP, an eighteen month transition period will be 
applicable. Appendices to the GOSIP specification describe 
advanced requirements for which adequate profiles have not yet 
been developed. 

50.3.3.6. GOSIP functionality. Currently, GOSIP addresses file 
transfer, access, and management (access and movement of infor¬ 
mation files among network users), and message handling systems 
(electronic mail or messaging between network users). GOSIP 
provides enough functionality to be generally useful for all 
government computer networking needs. If additional 
functionality is required to meet CALS technical data interchange 
and access needs, it can also be specified by the acquisition 
manager. 


50.3.3.7. Contracting for OSI delivery. To require OSI/GOSIP 
compatibility as a delivery or access mode, FIPS PUB 146 should 
be cited. The GOSIP architecture supports a range of protocol 
choices at different protocol layers. A subset of these 
protocols may adequately satisfy an individual program 
requirement. If a subset of the GOSIP protocols and service 
interface profiles are chosen, it is the acquisition manager's 
responsibility to ensure that all paths through the architecture 
are complete. 
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DATA PROTECTION AND INTEGRITY, 
DATA RIGHTS, AND RELATED ISSUES 
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10. SCOPE 

10.1. Applicability. This appendix provides guidance on data 
protection and integrity, data rights, change control, and 
related issues to government activities acquiring technical data 
in digital form or establishing CITIS functional integration 
requirements. It is applicable to all Department of Defense 
(DoD) components responsible for acquisition of weapon systems or 
related major ec[uipment items. 

10.2. Purpose. This appendix identifies issues that should be 
addressed by the acquisition manager, and suggests the best 
methods for tailoring the wording of standard DoD Requests for 
Proposal (RFP's) and Contract Data Requirement Lists (CDRL's) to 
allow and encourage the integrated preparation, government access 
to, and digital submission of deliverable data. 


20. REFERENCED DOCUMENTS 

See list of references appearing in Appendix A. 


30. DEFINITIONS 

See list of terms appearing in Appendix A. 


40. GENERAL GUIDANCE 

40.1. Contracting for digital data. A major thrust of the 
Computer-aided Acquisition and Logistic Support (CALS) program is 
the delivery of weapon system data in digital form. A second 
thrust is integration of the data bases which produce that data 
and make it available for use. Implementation of these 
objectives must be accomplished in a manner that protects from 
unauthorized access, use, or change: (1) information that is 
classified as having national security implications, (2) 
information that is contractor proprietary or competition 
sensitive, (3) information that is subject to export control as 
technologically sensitive, and (4) the systems that create, 
store, and distribute that information. Additional issues to be 
considered in contracts include data rights, privacy, and legal 
liability. 
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50. DETAILED GUIDANCE 

50.1. Data protection and Integrity. The goal of CALS data 
protection and integrity policy is to ensure the integrity and 
confidentiality of all CALS assets to the extent possible within 
existing regulations, procedures, etc. Inherent in the 
attainment of this goal is the requirement for adequate risk and 
data protection planning and implementation throughout the life 
cycle of weapon system technical data. The purpose of this 
section of the handbook is to aid acquisition managers in 
accomplishing system and data protection and integrity planning 
to ensure proper development, implementation, and administration 
for CALS programs and activities. This section of the handbook 
supports implementation of DoDD 5200.28, Security Requirements 
for Automated Information Systems. It is not intended as a 
substitute for the extensive specialized functional and technical 
guidance available on this svibject. 

50.1.1. Background discussion. The emergence of digital media 
has resulted in a new series of methods and techniques for 
unauthorized use and dissemination of information. The 
acquisition manager, other government users of technical data, 
and the contractor have a shared responsibility to provide an 
adequate level of protection in ail CALS-related delivery and 
access modes. The level of protection must be commensurate with 
the level of information sensitivity. Providers and users of 
technical data should recognize that evolving technology and 
standards for system and data protection are being matched by 
evolving technology for protection infringement. The acquisition 
manager should address system and data protection and integrity 
requirements early and continuously throughout the life cycle of 
the weapon system. The program office security officer should be 
thoroughly familiar with CALS concepts for delivery of data in 
digital form, and for interactive access by government users to 
contractor data bases and by contractor users to government data 
bases. Using this knowledge, the program office security officer 
should play an active role in selection of the appropriate 
delivery or access modes. The contractor should be advised as 
early as possible of the security-related requirements for 
technical data to be delivered or accessed in accordance with 
CALS standards and statement of work provisions. The contractor 
should be required to thoroughly describe the procedures to be 
implemented at each level of sensitivity to protect technical 
data, and the systems and networks hosting that data, from 
unauthorized use or abuse. 

50.1.2. Systems approach to data protection and integrity. Data 
protection and integrity requirements for CALS are divided into 
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six interrelated security disciplines: communications security, 
computer security, operations security, physical security, 
personnel security, and information security. These disciplines 
must be integrated into an overall systems approach. 

50.1.3. Goverxment data protection and integrity issues. 
Technical data generated in support of a weapon system 
acquisition program will include data that is unclassified. For 
Official Use Only (FOUO), subject to export control, corporate 
proprietary/source selection sensitive, or classified from a 
national security standpoint, (e.g., confidential, secret, top 
secret, etc.). Although the bulk of this data will usually be 
unclassified, the inferences which can be drawn from the 
accumulation of unclassified data (data aggregation) may dictate 
a higher level of classification for the data elements or the 
aggregate data. The delivery mode(s) selected for transmission 
of technical data to the government must provide a level of 
protection commensurate with the data's level of sensitivity. 
Multiple delivery modes may be specified in some cases. For 
example, a small classified appendix to an unclassified technical 
manual may be delivered in hard copy while the main body of the 
technical manual is delivered as a set of processable data files. 
For interactive access to weapon system data, provisions for 
access control and telecommunications security must be addressed 
in accordance with DoD and National Security Agency regulations 
and instructions. The procurement must clearly state what degree 
and levels of access will be required. 

50.1.4. Industry data protection and integrity issues. In 

addition to providing protection for technical data commensurate 
with government-designated levels of sensitivity, industry must 
deal with company proprietary, competition-sensitive, or 
liability sensitivities of data. This is the responsibility of 
the contractor's facility even if government personnel have 
interactive access capability. 

50.1.5. Telecommunications. The interrelationship and 
interdependency between telecommunications and computer systems 
are defined by Public Law 100-235, the Computer Security Act of 
1987. Government agencies and systems security steering groups, 
including the National Security Agency and the National Institute 
of Standards and Technology, have been given the responsibility 
to establish policies, standards, products, and 
technical/research centers. Encryption of classified or 
sensitive military data should be in accordance with procedures 
established by the National Security Agency. Encryption of other 
sensitive data should be by commercial practice commensurate with 
level of sensitivity. 
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50.1.6. Computer security levels. Information processing 
products are evaluated to determine the level of their capability 
to protect information from unauthorized access. This evaluation 
is performed in accordance with the requirements set forth in DoD 
5200.28-STD, The DoD Trusted Computer Systems Evaluation 
Criteria. One of the levels of information security is broadly 
categorized as system high. An information system that is 
operating at system high requires that all users with physical 
access to that system have a current security clearance 
equivalent to, or greater than, the highest classification level 
of any data resident on that system. A second level of 
information security is categorized as multilevel security. 
Multilevel security offers more advantages than system high to 
users who must deal with technical data whose elements are at 
different levels of classification or sensitivity. However, 
implementing an approved multilevel security system may pose 
major problems. An information system that incorporates 
multilevel security allows system access to users who have 
security clearances that are at a lower level than some of the 
data resident on the system. A multilevel security system must 
therefore protect information from unauthorized disclosure to 
individuals who have a lower security clearance, but who are 
authorized to access the system. All options and alternatives to 
multilevel security, including multiple physically isolated data 
bases, must be considered. 

50.1.7. Data protection and integrity requirements. Technical 
data generated, processed, and disseminated in a computer aided 
and telecommunications environment must be protected in 
accordance with applicable statutes, regulations, and guidelines. 
Some data will be classified, and its protection is defined by 
law, executive order, and directive. Most data will be 
unclassified, but its protection is still necessary for the 
suppliers and users of the data. System and data administrators 
must also plan for disaster recovery; although this issue is 
unrelated to system/data compromise, the problems associated with 
restoration of data of known integrity are comparable. 
Survivability of both technical data and the weapon systems 
supported by that data will require the application of data 
protection and integrity measures for information, hardware, 
software and operating systems, and weapon system components. 

Life cycle data protection and integrity modeling will be used 
as: 

a. A framework for analyzing all aspects of CALS data, 
protection and integrity. 

b. A basis for establishing data protection policies, 
plans, and procedures. 
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50.1.7.1. Industry. Appropriate data protection measures and 
standards are required when proprietary or technologically 
sensitive acquisition and logistics data are created, changed, 
transmitted, received, and stored in digital form. Effective 
industry application depends in part on the degree of control 
needed to meet data protection requirements, and the quality of 
the implementation and enforcement of those controls. To obtain 
early visibility and management of data protection and integrity 
issues, a risk assessment and security plan should be developed 
in response to anticipated weapon system program requirements as 
part of the offeror's proposal in response to an acquisition RFP. 
This plan should address levels of data protection for each 
access mode, and procedures for protection of classified data, 
with particular attention to interactive data base access and 
telecommunications. 

50.1.7.2. Government, since CALS technologies allow 
dissemination and use of industry-developed data beyond the 
control of the owner of the data, government access and control 
of this contractor information must be managed through the use of 
DoD-wide uniform standards. Data protection and integrity 
requirements will increase significantly as CALS encompasses more 
classified and sensitive information, and employs more automated 
systems to originate, communicate, and receive data. It is the 
responsibility of the program office to conduct a security risk 
analysis to identify anticipated data protection requirements as 
described in table 6. 

50.1.7.3. Risk approval procedures. Risk approval procedures 
should be established to ensure the acquisition manager is 
provided with information on risk, trade off, and cost/benefit 
analyses that is adequate to make an informed decision concerning 
optimal data protection and integrity procedures. Risk approval 
procedures are based on the recognition that achieving perfect 
data protection and integrity (i.e., the absence of all 
vulnerabilities) is not usually feasible. The goal of the risk 
approval process is to provide the weapon system program with the 
best security practicable, at acceptable cost, consistent with 
other critical program parameters. 

50.1.8. Considerations for implementation of data protection and 
integrity. System security engineering principles, as outlined 
in MIL-STD-1785, will be utilized to integrate data protection 
and integrity disciplines in an effective and efficient manner to 
achieve assured service, integrity, and confidentiality. Data 
protection and integrity programs will be developed on the basis 
of formal risk versus vulnerability assessment procedures. 
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TABLE VI. Identification of security by data item. 


SECURITY CLASSIFICATIONS 


* DoD REQUIREMENTS 

LEVELS OF SECURITY CONTROL 

TOP SECRET 

SECRET 

CONFIDENTIAL 

FOR OFFICIAL USE ONLY (FOUO) 
MOSAIC 

EXPORT CONTROL 

System level currently for 
classified information 
Transaction level currently for 
sensitive unclassified data 
Data element level in future 
CALS systems 

* INDUSTRY REQUIREMENTS 

USER PROFILES 

COMPETITION SENSITIVE 
COPYRIGHTED 

TECHNOLOGICALLY SENSITIVE 
COST SENSITIVE 

MOSAIC (applies to industry 
as well as DoD data) 

Access & Control (for example) 
by domestic company 
by foreign company 
by department 
by project 
by group 

Procedures and software rules for access control user 
profiles/ which becomes a matrix matching the data security 
level with the user profiles. 



50.1.8.1. Industry. In the transition from hard copy to CALS 
data interfacing and data integration technologies, the 
requirements for the protection of proprietary information will 
increase in sophistication and cost in proportion to the 
increased level of access control required. Access control 
issues exist at contractor/government sending and receiving 
sites, and in the telecommunication links connecting them. Data 
protection and integrity standards should be established and 
enforced early in the program in accordance with a CALS technical 
data security plan approved by the government program office. 
Access controls should be established in accordance with this 
plan. 

50.1.8.2. Goverxunent. Information and communication-computer 
data protection and integrity management for CALS technical data 
must be addressed in accordance with DoD 5200.1-R, Information 
Security Program Regulation, and DoDD 5200.28, Security 
Requirements for Automated Data Processing Systems. The process 
for establishing data protection and integrity requirements is as 
follows: 
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a. Establish data protection and integrity requirements 
using CSC-STD-004-85, Guidance for Applying the 
Department of Defense Trusted Computer System 
Evaluation Criteria in Specific Environments. For a 
given maximum data sensitivity and minimum clearance or 
authorization of a system user, a computer security 
category, ranging from Cl to Al, is required. 

b. Use DoD-5200.28-STD, the DoD Trusted Computer System 
Evaluation Criteria as a source for information pro¬ 
cessing product evaluation. The Evaluated Products for 
Trusted Computer Systems (called the Evaluated Products 
List) is contained in the Products and Services list 
that is prepared and published quarterly by the 
National Computer Security Center. 

c. After definition of information and communication- 
computer data protection and integrity requirements by 
DoD weapon system and data system acquisition managers 
and by security managers, requirements should be passed 
to contractors using DD Form 254, DoD Contract Security 
Classification Specifications. 

50.1.9. Implementation guidance. The acquisition manager should 
develop a program plan that incorporates a multi-disciplinary 
systems approach to meeting the data protection and integrity 
requirements of the program. This plan will identify responsible 
personnel and resources, and require government or contractor 
performance of: 

a. Data protection and integrity threat and vulnerability 
analyses. 

b. Data protection and integrity risk assessments and 
trade-off analyses. 

c. Data protection and integrity test and evaluation. 

d. Configuration control for security systems and trusted 
system components. 

e. Identification of vulnerabilities that remain after 
implementing all reasonable security measures. 

f. Periodic inspections to ensure compliance. 

50.1.9.1. Program Office Security Officer. Information and 
communication-computer data protection and integrity requirements 
must be addressed early and continuously throughout the life of 


137 





NIL-HDBK-59 
APPENDIX B 


the weapon system. Oftentimes, the most easily compromised 
information is that which is considered too fluid, too 
preliminary, and too incomplete to warrant serious data 
protection. The program office security officer should 
completely familiarize himself with CALS digital information 
delivery objectives and related data protection and integrity 
issues, as described in this appendix and in other DoD 
instructions relating to protection of classified and otherwise 
sensitive data. The program office security officer should fully 
participate in all decisions concerning access or delivery modes 
and media for technical data in digital form. These decisions 
should be made in a manner which is consistent with the CALS 
objective for the program, and which provide an appropriate level 
of protection at reasonable cost. In conjunction with other 
program office personnel involved in setting reguirements for 
delivery of technical data, the program office security officer 
should determine the anticipated data protection and integrity 
requirements for the program, including volume of data 
anticipated to be delivered or accessed at each level. The 
security plans proposed by the various offerors, and the security 
plans and facilities available at government activities which 
will receive and process technical information, should be 
reviewed and taken into account in recommending the appropriate 
method of delivery or access. 

50.1.9.2. Contract implementation. Determination of data 
protection and integrity requirements for technical information 
to be delivered or accessed, such as anticipated classification 
levels for technical manuals, engineering drawings, and other 
technical data, should be accomplished early in the program. 

Early dissemination of this information to potential contractors 
should be accomplished prior to award of contract, either as part 
of the bidder's briefing or in the RFP. This description should 
go beyond the scope of the DD Form 254, and should provide the 
contractor with a sufficient level of detail to develop a 
contractor data protection and integrity plan. The RFP should 
request a description of the offeror's proposed method for 
implementing data protection and integrity procedures for the 
protection of both classified information and information that 
the offeror anticipates being proprietary or sensitive from an 
export s^"\ndpoint. The plan should be used by the government to 
plan and ocquire the resources needed to receive, store, and 
process sensitive technical data at government facilities 
involved in the life cycle support of the weapon system. 

50.1.9.3. Suggested instructions to offeror language. The 

following language is suggested for inclusion in instructions to 
offerors: 




MIL-HDBK-59 
APPENDIX E 


The offeror shall develop a preliminary plan which addresses 
intended data protection and integrity provisions for tech¬ 
nical data to be developed and maintained by the contractor, 
and delivered to the government or accessed by government 
personnel. This plan shall be derived from the anticipated 
program data protection and integrity requirements provided 
by the government. It shall address levels and methods of 
data protection for all levels of technical data from the 
viewpoints of economy, impact on other program contract 
activities and schedule, and government plans for 
interactive access. It shall describe requirements (such as 
number and type of data encoding devices) to accomplish the 
data protection and integrity provisions contained therein. 
It shall be complete enough that the government can assess 
offeror's potential for compliance with data protection and 
integrity requirements while meeting the CALS objectives. 

50.1.9.4. Suggested statement of work (SOW) language. The 

following language is suggested for incorporation in SOW's for 
classified data: 

The contractor shall minimize the volume of information 
requiring specialized handling for purposes of data 
protection and integrity, and shall provide information at 
the lowest classification level practicable. For example, 
unclassified technical manuals are preferred over classified 
manuals, provided they contain adequate information to 
perform the function described therein. Largely 
unclassified technical manuals with a classified appendix or 
supplement are preferred over largely classified technical 
manuals. In organizing technical information in this 
manner, the contractor shall pay particular attention to 
items of information which by themselves are unclassified, 
but when taken together, allow classified information to be 
inferred. The government shall retain the right to conduct 
announced and unannounced inspections by security 
specialists at any time to review, audit, and account for 
classified materials. 

50.2. Data rights, privacy, and legal liability. (CALS related 
work in the area of data rights, privacy, and legal liability is 
being performed by the CALS Acquisition Task Group. Supplemental 
guidance will appear in the FY '89 update to this handbook.) 

50.2.1. Application of CALS standards. Application of CALS 
standards must be analyzed to ensure that adequate management 
procedures are implemented to control access to data that may 
require controlled distribution for reasons other than the data's 
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security classification. Access and distribution may be 
controlled because of any of the following: 

a. Sensitive technology as indicated by documents or 
computer files marked or annotated in accordance with 
DoD 5230.24, Distribution Statements on Technical 
Documents, and controlled in accordance with DoD 
5230.25, Withholding of Unclassified Technical Data 
from Public Disclosure. Refer to the relevant Service, 
Agency, or Command office, or, in accordance with 
Service or Command procedures, to the Office of the 
Deputy Undersecretary of Defense for Research and 
Technology. 

b. Rights in technical data. Refer to Defense FAR Supple¬ 
ment Part 27.4 and the basic data rights clause at 
52.237-7013. 

50.2.2. Liability and warranty. Liability and warranty issues 
must also be addressed. Liability is often confused with 
ownership, but is a more precise concept. It is possible to own 
a computer program, such as a word processing application, 
without having the right to copy it, nor responsibility, nor 
liability for its proper use. Adequate control of changes and 
determination of change authority is also a critical legal issue. 
These issues are conceptually the same in a CALS environment as 
in the current paper-based environment. However, the application 
of CALS technologies provides both an opportunity to better 
address these issues, and the potential for additional abuse. It 
is the responsibility of the acquisition manager, in coordination 
with supporting DoD legal counsel, to establish, implement, and 
enforce procedures and safeguards to preclude the opportunity for 
such abuse. The contractor shares a responsibility to develop, 
implement, and enforce corresponding procedures and safeguards. 

50.2.3. Information change management and configuration control. 

The selection of digital standards also requires review of manual 
and automated procedures for controlling and tracking data 
changes. Generally, the more functional utility provided by a 
data interchange or access standard, the more sophisticated and 
extensive must be the procedures for configuration management of 
the technical data. The ability to manage, control, and identify 
changes and change authority is absolutely necessary to proper 
assignment of liability and responsibility. 
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Preparing Activity 
OSD-Cii 

(PROJECT ILSS-0035) 


Review activities: 

Army - AM 

Air Force - 01, 02 

NSA - NS 

DCA - DC 

NSA - NA 

Other - NBS, DOE, GPO, NCS 

User activities: 

OSD - IR 

Army - AL,AT,AV,CR,EA,ER,GL,ME,MI,MR,SM,TE,TM 
Navy - AS,EC,OS,SA,YD 

Air Force - 11,13,14,17,18,19,68,79,99 


Custodians: 
Army - CR 
Navy - SH 
Air Force - 24 
DLA - DH 
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